Release Early, Release Often

This has a corollary that I'm a little less adept with: "Under promise, over deliver". 

In any event, uzCardSort, a mozilla based software solution to ease the process of having users organize your content or functions, has been released.  A preview release albeit.  I finally figured out a major OS X blocker, which also plagues Blozom, but with the card sort tool my Mozilla native drag and drop is busting.  Feedback from a OS X mozilla user would be welcome.
|||
Posted at NaN:NaN, Published in: Mozilla UI

Mozilla Bug Tracking Cluster Fsck

So tabbed browsing is the best thing since sliced bread. If you haven't gone into preferences and set control-click to open in a new tab, do it now.  If you aren't using Mozilla to browse with tabs, get it now.

However, it's only mostly implemented in Mozilla with several glaring inconsistencies.  There's no context menu option for open in new tab in the bookmark sidebar and worse, the control click option doesn't work for personal toolbar items.  Probably the most popular form of link access in the entire damn suite and it doesn't support the community voted best feature.

I hypothesize that user's are willing to work around inefficiencies when they don't know any better without a lot of grumbling.  However, when they clearly know there's a better way and it's just not exposed to them, the subjective impression of the software's usability is damaged to a much greater degree than simply a awkwardly configured dialog.

Why don't I just do it?  It already has a patch and this wonderfully cryptic string of keywords "mozilla1.0, mozilla1.2, nsbeta1-, polish" meaning yes, we really really ougth to do this.

But this isn't really the point I'm interested in... The larger question is how can a open source community produce usable software?  How do they arrive at relative importance of features and bugs?

In this case, bugzilla is getting in the way. Look at the trail of duplicates and bugs about the same general function across it's different instances in the UI. Several problems I can see here:

1. Lack of awareness in bug filers about the mapping between features and the files that enable them.  Since commits are reviewed on file by file changes, bugs are best filed in clear mappings between RFE and the underlying code.
2. The duplicate fiasco that is Mozilla bugzilla.
   
3. The intermingling of "wouldn't this related feature be cool" with debates on the merit of a particular feature.  Makes digesting this stuff hard work.
4. No common usage metrics that discusssions can reference for tradeoffs.

What else?  It's worth thinking about. My commenting system has not arrived, so if you wanna feedback, please do.

Responses:

• RK suggests that the component architecture in bugzilla should be a hierarchy mapped do a design document.  Even just the notion of a hierarchy for components that allows the different bookmark implementations (sidebar, toolbar, menu, url bar) within Mozilla to be grouped and bugs to be positioned and repositioned within this hierarchy.
  
  In his own words: Have an over all design document.  Then break it down into the individual features to be implemented.  Components effected can then be associated with that feature and individual bugs then assigned.  Bugzilla is a flat system.  It really needs to have more of a heirachy.  Every bug should have to be associated with a portion of an overall design document.
  
  Sidebar bookmarks are an interesting example.  A bug might touch several areas of the hierarchy.
  
  In addition to, or perhaps instead of, a design document, one might have a "usability goals" document which would help map bugs/features to usability goals. While a smaller project might manage a cohesive design document, the Mozilla project is a tough one for this approach, given that NS cares not about the Mozilla UI and is shackled (and blindfolded!) by the the Netscape 4 design.
  

|||
Posted at NaN:NaN, Published in: Mozilla UI