When developing entrepreneurial software the temptation is always to go directly from proof of concept or demo code to production. Customers want your application, and are excited about your product, you still don't have the $$ needed to really make it scalable and secure - but growth of customer base looms. After viewing the havoc that can be wreaked by a problem as simple as not allowing brute force attacks on a social networking site (Twitter and Obama's account) it is a good cautionary tale for any entrepreneur. The transition from proof of concept or demo must be planned in advance. Software should be evaluated for risk and the risk mitigated before widespread growth and acceptance of the product.
SANS recently released a list of the top 25 mistakes programmers make when creating software. Read it over. Is your proof of concept or demo software tested against these rigorous standards? If not, have you budgetted the dollars needed BEFORE you go into full production to evaluate and if necessary amend your code to take these issues into account? If not you might have some 'splainin' to do as Ricky Ricardo would put it when your customer's private information is compromised.
Thursday, January 15, 2009
Monday, January 5, 2009
Defining a simple interface
In our last article we talked about the process for determining the importance of features in a new agile software project. One of the most important features of any website, which is a "general" feature rather than a specific one, is creating an easy to use, yet powerful user interface. This is doubly important in developing web software since complexity on the user-interface side typically requires more coding and development than complexity on a dedicated application (due to working with multiple browsers). If your application becomes too complex it could force you into a front end development interface such as Flash or Silverlight due to the limitations of a browser based system. To retain the best cross-browser compatibility sticking with AJAX/Javascript/CSS/DHTML/HTML is the best solution.
In our last exercise we identified 85 new features to potentially be added to the product and gave them a subjective ranking based on making binary choices. How do we keep the product from falling over under the weight of so many features? How do we maintain the idea of a simple interface without sacrificing important capabilities?
One way to do this is to apply a subjective score to each feature for whether it ADDS COMPLEXITY (from a user or administrator's point of view) or whether it SIMPLIFIES the user interface. This should be pretty easy - if there are more buttons on the screen, user interface elements to learn, or processes to train someone on - then it ADDS complexity. If on the other hand it eliminates or streamlines processes, removes administrative burden, or simplifies already complex tasks - it REMOVES complexity. Remember here that we're not yet considering whether it adds CODE COMPLEXITY, we're only considering user interface complexity. This is a simple binary choice, and in most cases won't require a lot of discussion.
Let's say for instance that our current user interface requires a user to upload a graphic to the website for inclusion in a post, using the traditional "browse and upload" methodology, and that one of our suggested features (never mind code complexity yet) is to allow users to drag-and-drop a graphic onto a particular spot on the website and handle the upload itself - requiring no directory browsing to accomplish. Does this add or remove complexity (from a user point of view)?
That one's pretty easy - it removes complexity. We're replacing 5 steps (press browse, find a directory on your hard drive, select a file, click upload, link file into current content) into 2 steps (open directory and find file, drag and drop onto content where you want it positioned).
Let's look at an example that increases complexity. Say you want to allow users to chat while posting a blog entry, and to record that chat as a link to the blog. That increases complexity. You need an entirely new user interface for storing and displaying the chat itself, presence indicators to indicate who is available for chat, a way to link chats to blog entries, and a way to initiate and terminate chat sessions - all new administrator or user interfaces. This feature adds complexity (from a user point of view).
We're not really making a judgement at this point whether the complexity added is worth the perceived benefit - we're just determining whether it adds or removes complexity from a user's point of view. So for each weighted item on our list we add a column and record a zerp "0" if it simplifies complexity and a one (1) if it adds complexity. We can later add a weight to the "1" records if we want, or score the amount of added complexity on a sliding scale (1-5 where one might represent a single new button, and 5 would represent an entirely new interface and administrative burden). These are flash, subjective evaluations, and are done based on putting yourself in the end-user's role.
In our last exercise we identified 85 new features to potentially be added to the product and gave them a subjective ranking based on making binary choices. How do we keep the product from falling over under the weight of so many features? How do we maintain the idea of a simple interface without sacrificing important capabilities?
One way to do this is to apply a subjective score to each feature for whether it ADDS COMPLEXITY (from a user or administrator's point of view) or whether it SIMPLIFIES the user interface. This should be pretty easy - if there are more buttons on the screen, user interface elements to learn, or processes to train someone on - then it ADDS complexity. If on the other hand it eliminates or streamlines processes, removes administrative burden, or simplifies already complex tasks - it REMOVES complexity. Remember here that we're not yet considering whether it adds CODE COMPLEXITY, we're only considering user interface complexity. This is a simple binary choice, and in most cases won't require a lot of discussion.
Let's say for instance that our current user interface requires a user to upload a graphic to the website for inclusion in a post, using the traditional "browse and upload" methodology, and that one of our suggested features (never mind code complexity yet) is to allow users to drag-and-drop a graphic onto a particular spot on the website and handle the upload itself - requiring no directory browsing to accomplish. Does this add or remove complexity (from a user point of view)?
That one's pretty easy - it removes complexity. We're replacing 5 steps (press browse, find a directory on your hard drive, select a file, click upload, link file into current content) into 2 steps (open directory and find file, drag and drop onto content where you want it positioned).
Let's look at an example that increases complexity. Say you want to allow users to chat while posting a blog entry, and to record that chat as a link to the blog. That increases complexity. You need an entirely new user interface for storing and displaying the chat itself, presence indicators to indicate who is available for chat, a way to link chats to blog entries, and a way to initiate and terminate chat sessions - all new administrator or user interfaces. This feature adds complexity (from a user point of view).
We're not really making a judgement at this point whether the complexity added is worth the perceived benefit - we're just determining whether it adds or removes complexity from a user's point of view. So for each weighted item on our list we add a column and record a zerp "0" if it simplifies complexity and a one (1) if it adds complexity. We can later add a weight to the "1" records if we want, or score the amount of added complexity on a sliding scale (1-5 where one might represent a single new button, and 5 would represent an entirely new interface and administrative burden). These are flash, subjective evaluations, and are done based on putting yourself in the end-user's role.
Subscribe to:
Posts (Atom)
Posts
