Most of the software out there is not very good. This is a sad fact, but we users have to deal with it. Software can be bad in many ways: annoying bugs, ugly icons, bloated and inconvenient interfaces, and more. The main cause of these disasters is lack of planning and the programmer’s inability to understand what the user really needs. This article describes the initial stage of software development, when a solid vision of the product has to be formed and the interface has to be planned. This area has not been well covered by authors, and this lack of knowledge is the cause of bigger disasters in later stages of development. Code ’n’ Run (sign up for it today!), Techmic’s web-based site editor, will be used as an example so readers can learn how to plan software that works on the web and is comfortable to use each day for many hours.
Contents
A Big Change
A big change occurred in the software industry not too long ago when web-based software started to evolve. Instead of buying a program, installing it on one computer and using it until the system gets reinstalled, or switching to a different computer, users now can use software in their browsers. Look at web-based email programs like Gmail or Yahoo! Mail, text editors like Google Docs, or even music players like Grooveshark. It is convenient to keep everything on the web in the cloud and access it from anywhere whenever you want. Web-based software is also very secure, since the servers that are running the service are much more protected than a single computer.
Everything that is needed for comfortable work is stored together in one place—temporary text files with passwords, flash drives, and sticky notes can be abolished. There is only one browser needed to access it all after the user is authenticated. Recently, big companies started moving actively in the direction of web-based software. Soon most software will be online, and individual computers will only serve as terminals to connect to a needed service and access its memory, computational power, and software.
Web-based applications have the same features as normal desktop software and websites. However, it takes more skills to develop web-based applications as compared to desktop applications; developers must know HTML, intense JavaScript, server-client interaction, databases, usability in a web browser, the ability to run a service on different devices, and others. This article does not touch much on the technical aspects of web-based software, but instead focuses on planning the software, simplifying the interface, and creating a great experience for the user.
Starting with the Idea
The first thing to ask before doing anything is: does anybody need what I am about to do? If everybody asked this question, people would not suffer from countless clones and bad products. In web and software development it is very important to understand whether people need whatever is about to be produced. If the question above is too hard to analyze and come up with an answer, another question can be asked: am I going to use what I am about to make? A lot of developers find joy in developing for themselves, which is totally understandable. However, a developer is responsible for the quality of a program or web service if it will be used by others. If the answer to the second question is “yes”, then it should be produced because the odds of having somebody else in the world who would use it are high. If the answer is “no”, then a developer should not even bother starting to develop.
Let’s look at the example of Code ’n’ Run (sign up for it today!). Does anybody need an elegant web-based code editor for websites? Yes. People who want to be extra productive, be able to edit from anywhere, don’t want to always remember passwords to their projects, and work in a simple, non-bloated environment would appreciate the idea of Code ’n’ Run. And, most importantly, I, as a developer, would use this editor anywhere. Since the idea has passed the initial filter, what’s next? Now developers need to get real, and not just by singing Steve Balmer’s song. Here is advice on the process of getting real and making good software from the Getting Real book, whose authors mastered the art of solving problems in making web-based software:
“Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.
Getting Real foregoes functional specs and other transitory documentation in favor of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That’s what your customers are going to see and use. That’s what matters. Getting Real gets you there faster. And that means you’re making software decisions based on the real thing instead of abstract notions.
Finally, Getting Real is an approach ideally suited to web-based software. The old school model of shipping software in a box and then waiting a year or two to deliver an update is fading away. Unlike installed software, web apps can constantly evolve on a day-to-day basis. Getting Real leverages this advantage for all its worth.”
Planning Features
It is unfortunate, but most programs are overstuffed with features. Programmers who plan their software and websites do not understand that nobody is interested in how skillful they are in terms of implementing new features. Users are interested in the usefulness of these features and an interface that makes sense. Companies like Apple and Google are great examples of how well-made software and web services should be: a straightforward interface with only features that are needed for productive and comfortable work.
Browsers are operating systems of web-based software. Just like in two major operating systems that set different standards for software (elegant and useful MacOS versus chunky and confusing Windows), browsers set this standard for web-services as well. Google Chrome and Apple Safari are the best browsers that give users the most satisfactory and fast experiences on the web with minimum features. Internet Explorer is not so good; it is an example of anti-open standards, and is the slowest and most insecure piece of software in the history of computers. Mozilla Firefox is somewhat in the gray area: it supports the latest standards, but in the past couple years it has become slower and now has features that are not well implemented compared to Chrome and Safari, letting plug-ins fix it (often not in a good way).
After looking at the two best web browsers, it is easy to determine which services were inspired by them or by the principles that they promote. Basecamp (helps to get projects done quickly), Google Docs (the best text processor for the majority of tasks), Gmail (the best and quickest emailing service out there), and some others are great examples.
Let’s look at an example of the planning “dialogue” that you should go through to figure out the must-have features of Code ’n’ Run.
What features are important for the web-based website editor to have? First of all, its basic function is to load and save files to the server, which should be done in one action as quickly as possible. The second thing is the actual editor. It is supposed to be fast, have a code highlighter for all major syntaxes, and be searchable. Here we discover a necessary feature: a search function. There should be a quick search option with just one input field and a more advanced search option with a replace input field, an option for regular expressions, and a case sensitive search.
The rest of the features listed are unnecessary since they are not needed to do the basic tasks that are described above. However, some additional features can be added based on the user’s preferences. Another thing that would be helpful is a version of the editor that would run well on tablet computers, since they are the next best for editing code. The only tablet computer that is popular and well-made today is the Apple iPad, so a separate version of the editor that uses the touch features of the device should be made, which can be considered a separate feature. All other platforms are irrelevant. For example, it is almost impossible to edit code on mobile devices, but if desired the regular version of the editor can be uploaded.
Another feature that can be added is the preview. It would be especially useful on the iPad version, since there will be no need to switch tabs. This feature could be a foundation for other desired features such as a FireBug-like console.
Isn’t it frustrating to see a boring list of projects and try to remember what the name of the one you need is? To solve this problem the enhanced sites list feature can be added. It will show screenshots of sites in the descending order based on the date of the last access of the project, making it easier for the user to select the right site.
The settings feature is almost always a must, and in the case of a website editor its purpose may be to set the interface so users can minimize it or to change the settings of other features. The key for settings is to make them minimalistic and clear. It should not be a panel that stuns the user by its view.
These are the features desired by most developers: file loader and uploader, code editor, search, interface for an iPad, preview, and settings. At this point, any more added features to Code ’n’ Run should be specific to the environment in which it will be used. For example, if it is used in a company, version control must be implemented. But if the user is a beginner in programming, a reference feature that will use online sources can be added to the editor, so if something in the code is unclear it can be answered in one click by just selecting a name of some PHP function and requesting information from php.net. These are obvious features and they have already been implemented in other editors, so they can be explored and adapted by Code ’n’ Run .
What about features that have never been implemented by other developers that might be needed for your software? It is okay to experiment with them, but only with one feature at a time. It is a bad idea to stuff software or a service with something that has not been tested yet that can cause bugs and unsatisfactory user experiences. In Code ’n’ Run, a feature called “The Heart”, which basically is a list of favorites, is being tested. The user can add a file, folder, or the whole chunk of code to this list, label it under a certain color, and access it later at any moment. The Heart was proposed as an alternative to having a bunch of files opened all at once and keeping chunks of code saved in temporary files. Isn’t it an elegant solution?
To summarize, let’s see which features were isolated in order to get the best web-based code editor for websites. The primary features are FTP access and the actual code editor. The secondary features are the search, the enhanced sites list, the iPad version, the preview, and the settings. The specific features are the interactive documentation and version control. Finally, the experimental feature is the favorites list (represented with a heart). Once the plan for features is rock solid, it is time to develop the interface for these features.
Getting Signal Instead of Noise
Designing good interfaces involves mastering the art of understanding how humans interact with information and tools. Not everybody understands that, which results in loads of low-grade interfaces, icons, and feature implementations. Some people think that design has to do something with making it pretty. That is only partially true. Design is really about solving a problem in the most elegant and simple way possible. This results in prettiness, but is not the main focus. If a designer tries to make something pretty without realizing the needs of users, the result will be crap. So, designing an interface involves making sure the user has no trouble interacting with the application features. When one hears a sound, he or she can tell whether it is a noise or a signal; the same applies to the interface— a signal is something that makes sense, while noise is something disturbing and incomprehensible.
The first thing that separates a noisy from a quiet environment is the skeleton of this environment. If all elements are organized in a random fashion, then it is hard navigate through such an interface. However, if a typographical grid is applied to the interface, all elements become part of a structured composition. A typographical grid is a structure made of a number of intersecting vertical and horizontal lines that serve as an armature on which an interface designer can organize buttons, icons, input fields, and other elements in a rational and visually-pleasing manner.
After the grid is built, it’s time to look at the details and combine features with the interface. All features that Code ’n’ Run has can be represented with icons as well as some of the decorative parts that will be described later. Well-designed icons will tell the user right away what a function does. Icons were first developed as tools for making computer interfaces easier for beginners to grasp in the 1970s at the Xerox Research Center. Now many icon designers have forgotten the original purpose of icons, and subsequently create icons that do not make sense whose function can only be guessed at. A lot of modern interfaces have adopted these kind of icons, which makes them much harder to use. If it is impossible to create an icon that will describe its purpose, then it is better to write in words what it does. Due to the small size of icons, they have to be designed in the resolution that they are going to be used in. For example, a 64 by 64 icon should not be a smaller copy of a 600 by 600 image, otherwise the smaller details will disappear and the bigger once will get smeared and ugly.
Let’s move on to even smaller details of the interface: the decorative parts. Decorative elements should not create any noise or distractions either; instead, they should be helpful in accomplishing tasks. Lines separating elements should not be too invasive, dark, or bold. For Code ’n’ Run, it is a good idea to separate active folder from files and folders (those can be represented by smaller icons and be decorative elements themselves) in the file manager and tabs with opened files to make each of them stand out more. In order to visually separate larger elements in the grid, like the file manager and the code editor, lines can be used as well. However, it is important not to overload the interface with lines: vertical lines should only be used to separate large elements and columns in tables; horizontal lines should be used to separate large elements, lists, and table rows.
Shadows, glows, and gradients can be nice in some cases, but for an adequate working environment they are not necessary. Shadows and glows are usually used by amateur designers on buttons and headings. This often creates a “dirty” look and is visually confusing for users to navigate. Buttons should be as simple as possible, incorporating the color scheme of the product. Gradients can be used to make them more appealing, but only if one has a good sense of aesthetics. Gradients can be also used on panels to make them blend more into the interface.
Access to features in any application must be easy: main features should be accessible in one click. For example, in Code ’n’ Run all primary, some secondary, specific, and experimental features should obey this rule. Some of the secondary features are not as important, and if there are already two many features that have quick access buttons and icons, it is better to hide them into menus. Keyboard shortcuts have to be implemented as well, such as standard ones like ctrl-f (apple-f on macs) for searching and the ones specific to the application.
Apple is great at designing interfaces and providing adequate guidelines for developers. That is why most of the popular software for macs is a pleasure to use. After releasing the iPad, developers and users experienced something completely new: a large, full-blown touch screen interface. Code ’n’ Run can change the coding experience with an iPad by giving developers an opportunity to abandon the mouse and do all operations by hand. To develop a web-based application for an iPad, it is a good idea to follow Apple’s user experience and UI element guidelines for the best results. On top of all interface element design that is recommended by Apple, it would be good to think of some of the features that are not trivial such as an extended keyboard with special symbols that are used in programming and buttons for the most popular actions such as save, redo, and undo.
What Happens After?
Well, next the actual implementation, testing, and release happens, just like in books on software engineering. These three stages also have to follow the getting real principle, which is the major part of the agile methodology in order to provide well-made software. It is easy to grow beautiful code, test for bugs, and release to users if there is a foundation of firm understanding of the principles described earlier in this article: realize the need, the features, and the interface. Only after that can you implement, test, and release.