Nicollet.Net

← Stylesheets | Localization →

So far, we have been thoroughly avoiding the core subject of developing software: users will spend most of their time using the software, not logging in, resetting their password or changing their account settings. The single most important part of software, more deserving of an effort than any other part of the system, is the part that lets the users accomplish whatever the software is intended to solve, and it is this specific part that the software author must design to be of utmost simplicity so that it does not hinder users at all.

First, to quote Joel Spolsky:

Avoid the temptation to add new fields to the bug database. Every month or so, somebody will come up with a great idea for a new field to put in the database. You get all kinds of clever ideas, for example, keeping track of the file where the bug was found; keeping track of what % of the time the bug is reproducible; keeping track of how many times the bug occurred; keeping track of which exact versions of which DLLs were installed on the machine where the bug happened. It’s very important not to give in to these ideas. If you do, your new bug entry screen will end up with a thousand fields that you need to supply, and nobody will want to input bug reports any more. For the bug database to work, everybody needs to use it, and if entering bugs “formally” is too much work, people will go around the bug database.

This is in fact a specific case of a more general trend: the more steps an user has to take to accomplish something, the fewer the users who actually accomplish it. It may sound obvious if spelled this way, but it’s easy to get distracted and forget about it for a second and you end up with a system that is too complex to use.

If your software only has one field in the form for its core functionality, then adding a second field doubles the amount of work required to use the system.

If you look closely at the evolution of Facebook over time, you will notice that it tends ingreasingly towards the one-field model. Want to update your status? Use the form at the top of the page. Want to link to a web page? Use the form at the top of the page. You can even use that form to add images or movies. And if you’re on a profile, you will be writing to the wall of that profile instead of your status, but the field will be the same.

The success of Twitter can probably be attributed to a similar process: you type, submit, and you’re done. It’s so easy, there’s absolutely no reason not to do it!

JITBrain is about making issue tracking so easy you don’t even notice the user interface, even if this means sacrificing other features along the way.

Full-featured software products that people don’t use to their fullest are not always better than software products with few features which are used all the time.

In other news, who is the enemy of the JITBrain project? What forces are we trying to move against by providing an alternative? There are four main opponents here, representing things that I want to improve upon:

• Todoist, the self-proclaimed best todo-list and task manager. This is our main competitor for the “individual todo-list” part of JITBrain. I want JITBrain to make entering new tasks easier, and to make processing existing tasks easier.

• The Mantis bug tracker (Bugzilla would have been another choice here, but I happen to be more familiar with the former). Mantis, while fairly well-featured, also strives to remain very simple. JITBrain should be even simpler for the user to manipulate, while remaining reasonably equal on the feature side, if possible.

• Alfresco, while being a document management tool, is a prime example of what the user interface should not look like. The default user interface breaks “refresh” and “back” buttons, requires dozens of clicks and mandatory fields to do most tasks (from adding a new file to starting a workflow to commenting on a file), and requires several full roundtrip HTTP requests along the way. This makes using it almost painful (which explains why improved interfaces and explorer-based manipulation are provided).

• Post-it notes. These are the tools of choice for remembering small things, such as a phone number, a thing that absolutely needs to be done, and so on. A paper block used to jot down ideas is in the same category. JITBrain, by definition, cannot support feature such as “sticking to the keyboard”, “carrying around outdoors” or “drawing doodles with a pen”, making this a losing battle.

The most elementary operation performed in JITBrain is to post a new item—jotting down a task or piece of information. Let’s take a look at how the other four solutions create an item (the basic unit of data in the system, with default settings):

Mantis does something like this:

1. Click the “Report” link in the top menu bar.
2. Wait for the report page to load.
3. Select and fill the subject line.
4. Select and fill the description.
5. Click the submit button.

Alfresco requires the following for uploading a file:

1. Click “Add Content” on the top right side.
2. Wait for page to load..
3. Click “Browse” button.
4. Use the dialog to find and select the file.
5. Uncheck the “edit properties” checkbox.
6. Click the submit button.

It also requires this when typing in a new file:

1. Click “Create” to open the create menu.
2. Click “Create Content” to open the wizard.
3. Wait for page to load.
4. Type the name.
5. Uncheck the “edit properties” checkbox.
6. Click “Next”, wait for page to load.
7. Enter the file content.
8. Click “Finish”.

Todoist does the following:

1. Click “Add item” or press ‘a’ to open a new item.
2. Type the item text.
3. Press “Enter” to submit.

Post-It Notes need the following:

1. Pick up pen and block.
2. Write item on paper.
3. Stick note to something.

The number of steps required in the Todoist case is much smaller than the Alfresco or Mantis cases, and it also does not require lengthy page loads at many steps: the only latency is sending the instructions to the server in AJAX, which is reasonably fast.

What I will do:

• The form to add a new item will be present on all pages where adding items is relevant. These will be the user pages to send messages to other users or keep information for yourself, the home page which acts like your own user page when posting items, and group pages which let you add tasks to projects or events. It is imperative that the user be able to add a new item within the active context without having to move to a new page.

• The form will consist of a button and a textarea. Using a normal input field would have allowed submitting by pressing “enter” (like Todoist) but would have prevented the user from entering multi-line items. Since I expect multi-line bug reports to be frequent, the textarea is a lesser evil that requires “tab-enter” (like Facebook) to submit a report.

• In order to be easily selectable by low accessibility (or tab-happy) users, I set up the tab sequence so that the first selected element is the textarea, and the second selected element is the submit button. So, I can open the page, “tab”, enter my description, “tab” and “enter”. And, of course, “shift + tab” back from the button to the textarea.

• For obvious screen real estate reasons, the form has to be small when not in use, but large enough to accomodate user input. To this end, I will imitate the Facebook input form by having the input field enlarge itself as the user types, for instance by using an appropriately patched copy of jQuery.autogrow.

Warning: while jQuery has a fairly permissive licensing model (both MIT and GPL licenses), jQuery.autogrow is distributed only as GPL. While the license for the entire project has not been determined yet, it is important to keep in mind every use of a third party library, because it’s easy to end up with mutually exclusive licenses (imagine using a proprietary library and a GPL library in the same project: you cannot distribute your code anymore!). So, even though jQuery.autogrow is an interesting project, I will have to either write my own or ask the author for an MIT license—que sera sera.

The result code looks like this:

<?php // views/newitemfield.php

  class NewItemFieldView
  {
      public static function Render()
      {
?><form id="new-item" action="#">
  <table>
    <tr>
      <td>
        <textarea tabindex="1" id="new-item-text" rows="1" cols="0"></textarea>
      </td>
      <td>
        <button tabindex="1" type="button" id="new-item-submit">Add</button>
      </td>
     </tr>
  </table>
  <script type="text/javascript">
     // <![CDATA[[
     $(function(){
       $('#new-item-text').autogrow({minHeight:14,lineHeight:14});
     });
     // ]]>
  </script>
</form><?php
      }
  }

Simply call the render function wherever necessary and it will insert the entry form, ready to work for you (of course, you have to decorate ‘#new-item-submit’ with the appropriate JS to have it work).

← Stylesheets | Localization →