Mingle Tip: Search Mingle Projects Directly In Firefox

Do you love using Firefox’s built in Google search? Wish there was a way you could do that with your Mingle projects? Well, now you can with the code below.

I’ve provided a download of the xml file here.

You’ll need to edit the file to point to the Mingle project you want to use the search tool with and then you need to install it into your searchplugins directory for Firefox, which for Windows is probably something like

C:\Program Files\Mozilla Firefox\searchplugins

and for Mac is something like

/Applications/Firefox.app/Contents/MacOS/searchplugins/

Drop the xml file in the folder and restart Firefox and you’ll have your new Mingle search up and running. It should look like this

Note: I’m working on getting this to work as described in this mozilla dev article for Mingle. It shouldn’t be too hard since we can modify views in Mingle. I’ll blog about it if people are interested.

May 20, 2008 | Filed Under Design, Mingle | Leave a Comment 

PSA: Tab Between All Controls On Mac

I normally love the Mac’s design decisions, but one thing that’s always maddened me is that by default you can’t tab between all controls on webpages, etc. I finally got that fixed today with an article from lifehacker.

Click the “All Controls” radio button at the bottom of the Keyboard & Mouse pane in System Preferences to right this wrong.

Bliss.

[via]

May 14, 2008 | Filed Under Design, Life | Leave a Comment 

When Distrust Turns To Disdain

While taking computer science classes in college, I was taught to distrust a user’s input in all cases. The theory goes that a user’s data can’t be trusted because it could be malicious or just a simple mistake that causes your program to have an error with input it didn’t expect. So you protect your system from incorrect user input and sanitize it. It always felt like one of our dirtier secrets to me, however I fully advocate the practice in code.

My problem comes when the people building software turn from distrusting their user’s input to having a level of disdain for the users themselves. It starts innocently enough with the engineering principles I described above, but can sometimes turn into small things like, “Our users won’t understand that,” and starts to slip into things like, “Our users are dumb, so we won’t do that.” If you’ve started to hate your users, you’ve gone too far. If something is too complex for your users to understand, it’s your job as the developer/engineer/analyst/etc. to make it so that they can understand it. If you think of your users like idiots, your system will reflect that and they will notice.

If your job is to design software for people to use (which, is pretty much all software), make sure you work with the user, instead of against their best interests.

May 9, 2008 | Filed Under Design, Work | Leave a Comment 

Developers Don’t Read Stories, So Talk To Them Instead

In Jakob Neilsen’s How Little Do Users Read? he sites an ACM study that has found that people typically only read about 20% of content on a page on average, with a max of around 28%.

This just confirms my suspicion that developers fully don’t read the stories that I write for them, even though they are highly focused and relevant to what they are looking for. Instead of reading, they skim and look at the screenshots I provide.

What can we take away from this? Treat stories as a conversation point, rather than a full design spec. If your devs have to read thousands of words in your stories, they are too big. Talk to your team and make sure people understand what you are trying to do.

At 130 words above, most people have read only 26 words in this article, meaning they’ve barely read the first paragraph. Scary.

May 6, 2008 | Filed Under Design, Work | Leave a Comment 

What Is The Shelf-Life Of A Requirement?

I like to think of requirements as being perishable. They have a certain shelf life before they are developed and then they start to smell funny and eventually go bad as they get out of date. Different sorts of requirements have different shelf-lives.

Master Level Story

The high level stories written at the beginning of a project and turned into a master story list can either have a long shelf life or a short one. If the requirements are not beginning to be broken down and worked on within a week or two, they get stale. Longer than a few weeks, into a few months or more, they should probably be thrown out and at the very least reevaluated. Why? Because your business may have changed in that time. It may not make sense to build those features that made sense a month or two ago.

Release Level Story

Release level stories are good for planning and immediately getting started on detailed analysis and development. They have a short shelf life based on their master level story freshness, plus any ongoing work in an application. For instance, if some implementation was decided on in a release level story and some technology change has made a card obsolete because it is building the wrong thing or makes the wrong assumptions, it’s useless.

Iteration Level Story

An iteration level story only has a shelf life of a few days after it’s been analyzed and not developed. More than a week or so and things can change so drastically in a project that they are not accurate anymore.

Shelf-Life After Development

After development, stories have a much longer shelf life. They can be referenced through various parts in the development lifecycle with the exception of stories that have been overwritten by new ones and those should be tracked as they occur.

Domain documents like systems architecture design, major domain concepts in your app, etc. are useful even longer.

Considerations

Keep in mind that all of these levels of stories interact. Master > Release > Iteration. They flow in that order and if the master level stories are old and no longer good, they need to be reevaluated. Otherwise, spending time to break them down will be a waste of time and even worse, implementing them can cost real money in the marketplace.

Constant prioritizing and re-evaluation will keep stories fresh for use by the development team. Don’t expect to be able to pull bad apples from storage and make some great apple pie.

May 1, 2008 | Filed Under Work | Leave a Comment