Thread

ExpressionEngine is an incredibly flexible system, capable of handling many different types of data.  The reason for this is the underlying power and flexibility of the Weblog Module, its Custom Field Sets, Category Groups, and Statuses.

On our own site here at ExpressionEngine.com, we have used that flexibility to run the Bug Tracker.  I often see the question, “when will you release the Bug Tracker module?”  Well, the answer here is simple: there is no particular Bug Tracker module!  The Bug Tracker is created out-of-the-box using the power of the Weblog Module.  In this series, we’ll explore how you, too, can leverage this power to create your own Bug Tracker.

This series does assume that you have gone through the Quick Start Tutorial and have a basic understanding of how to create and assign custom field, category, and status groups.

Shall we begin?

::takes notes::

Hi Lisa, great idea for a project series. Will the project be able to be built with the core version, probably not?
Could you post a screenshot of the sections, forms, etc that are not available to core users?
Maybe just this page:
http://expressionengine.com/bug_tracker/report/
Thanks looking forward to this series.

You’ll be able to build much of the bug tracker, but down the line we will allow submission of bug reports by logged in members, all on the front-end, so that will not be possible with Core.

There is nothing that I’ve done yet that is not available to Core users. =)

Nice ideas for a series ... will you offer the combined results in form of a publication afterwards? 😉

Hrm.

Great idea for a series… and timely too. I am about to start building a Property Condition/Comments tracking system for a local Real Estate agent and am reasonably sure I can do this in ExpressionEngine. Looking at your Bug Tracker there is a reasonable amount of common ground so I have no doubt this series will help greatly.

I have to agree that this series is a good idea. And I like that you guys are seeking to educate folks on how to use your tools. So why not use something like ScreenFlow from Vara Software and actually walk us through it using a screencast? Just a thought.

Marcus: Yes, the idea here is to highlight different types and formats of content can help - so I definitely am hoping that folks can make the jump from this type of data to other types, and see just how flexible everything is.

ignite: I considered that, and played with ScreenFlow last night.  It’s pretty darn slick, eh?

That said, while I could certainly do this in a video format, my personal feeling is that it is *harder* to reference and follow for someone trying to work through the tutorial.  A text format, with links and step by step instructions on where to click, seems to me to be easier to switch back and forth between windows and actually *work* through the tutorial. 

Furthermore, a text format is more widely available to people with slower connection speeds or older computers, and more accessible to people with a wide variety of issues that may still wish to use ExpressionEngine. 

So, while I may consider supplementing the tutorials, as I go along, with images or even brief video - for now, my feeling is that the main tutorial should remain as text.

Yes, it’s very cool. I guess I can see where you’re coming from. For me tho, I find it easier to learn by watching. Reading it and actually seeing it done are so very different. When you read read a tutorial, there is a certain amount interpretation that is involved. One could read a particular line and think, “did she mean this or this?”. But when see someone one actually show you the steps, there are no questions what was meant. Plus going back to exactly how it happened is, imho, easier since I just move the scrubber backward to re-watch the part I didn’t quite understand.

With regard to text being more accessible for those with slower speeds, I think we’ve moved beyond the time where that was as big of an issue as it used to be. I think it is important to be mindful of it but I think the majority of your audience would be the ones with better connections than average internet users.

Either way you approach it, I and many others are thankful that you putting such time into educating your users. Kudos.

ignite, I wish it were true that everyone was on a high-speed connection. However, we have many, many users that are on dialup speeds, or behind major security systems that severely restrict access.  These tutorials really do need to be accessible to all of our customers.

In any case, I think that you’ll find that much of the tutorial will not actually lend itself to a video, as it will be primarily code snippets placed in a template - and those are *much* better when you can copy and paste them, which a video will not allow for.

I will consider, when appropriate, images and video as supplementary materials - I like them, too - but they’re not always an appropriate format for what is being shared. =)

“Copy and paste” IS pretty handy! 😉 Thanks.

Edit: Btw, I didn’t say that “everyone” was on high-speed, just the “majority” of your user-base.

looking forward to complete the series! Very Nice.

In the beginning of the tut Setting up the Infrastructure did we need to set-up a new Field Group?

Thanks for the nice tutorial,

Andy

Hi, Andy - yes, you’ll need a Field Group to put those custom fields into. =)

Hi Lisa, hey in your custom fields you mention Field shortname, is that the same as the Field label, in the control panel?
Which field would be…
Field Name: Details
Field Shortname: bug_tracker_details
for example?

Should field instructions require anything just yet also?
————————————-
From the control panel:
—————————————
*  Field Name
Single word, no spaces. Underscores and dashes allowed
 
*  Field Label
This is the name that will appear in the PUBLISH page
 
Field Instructions
Instructions for authors on how or what to enter into this custom field when submitting an entry.
———————————————-

Also the mention of Custom Entry Statuses: new confirmed etc. didn’t require anything to be created, just yet?
@edit: Hey I found custom entry statuses, is there no way to remove Open and closed, or are those still required status types to go along with the other 5? I saw no way to remove open and closed.

thanks so much
-ty

@ Marcus Lee: Awesome suggestion about the property conditions/complaints, that would be handy for realtors, or apartment owners, I’ve got a nice client site now with several apartment complexes. I wasn’t coming up with any ideas on customizing it from a bug tracker to something else, otherwise. Any other ideas on turning the bug tracker into some other useful solution, anybody?