Simplicity

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the term “simplicity” when we refer it to a software product. There have been an old ‘80/20’ rule meaning that 80% of the people use 20% of the features. So, you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In a period in the past, dozens of companies tried to release ‘lite’ word processors that only implement 20% of the features. Most of the time, they gave their program to a journalist to review, and the journalist reviewed it by writing their review using the new word processor, and then the journalist tried to find the ‘word count’ feature which they needed because most journalists have precise word count requirements, and it was not there, because nobody in the target 80% would use this feature. The journalist ended up writing a story that attempted to claim simultaneously that lite programs were good, bloat was bad, and he could not use this program because it would not count his words.

Making simple with 20% feature products is an excellent bootstrapping strategy because you can create them with limited resources and build an audience. So, you sell “simple” as a wonderful thing and coincidentally, it’s the only thing you have the resources to produce. Bootstrapping strategy has advantages in certain situations, however, it would not be good for long term strategy because there’s very few obstacles to prevent the next two-person startup from cloning your simple app, and because eventually you can’t fight human nature of wanting the features.

Success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control. All of these features share a common character of having benefits that customers like and pay for, but none of them can really be described as “simplicity.” With many years of experience running his own software company, Joe Spolsky saw that nothing he have ever done at Fog Creek has increased the revenue more than releasing a new version with more features. When a new version came out with new features, there was a sudden, undeniable, substantial, and permanent increase in revenue.

It is fine to use the term “simplicity” to refer to a product as meaning that the user model corresponds closely to the program model, so the product is easy to use. More, it is fine to use the term “simplicity” to refer to a product with a spare, clean visual appearance. However, if you think simplicity means “not very many features” or “does one thing and does it well,” you can’t go far with a product that deliberately leaves features out.

 

Article: https://www.joelonsoftware.com/2006/12/09/simplicity/

 

Advertisements

Choices

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about choices or options that software designers give users during they are using programs to accomplish their tasks.  Pull up the Tools | Options dialog box and you will see a history of arguments that the software designers had about the design of the product. Some programs ask users to make so many choices. Even most users don’t understand much about or see it unnecessary to make some of the choices; as a result, users will be distracted or confused. Asking the user to make a decision isn’t in itself a bad thing. Freedom of choice can be wonderful. People love to order espresso-based beverages at Starbucks because they get to make so many choices. The problem is that you ask users to make a choice that they don’t care about. Actually, users care about a lot less things than a software designer might think. They are using your software to accomplish a task. They care about the task and really want to accomplish it. If it’s a graphics program, they probably want to be able to control every pixel to the finest level of detail. If it’s a tool to build a web site, you can bet that they are obsessive about getting the web site to look exactly the way they want it to look. They do not, however, care one whit if the program’s own toolbar is on the top or the bottom of the window, or how the help file is indexed. They don’t care about a lot of things, and it is the designers’ responsibility to make these choices for them so that they don’t have to. Sometimes, it is very hard to make a choice between conflicting requirements and the designer couldn’t think hard enough to decide which option is really better. Therefore, designers try to abdicate their responsibility by forcing the user to decide something, they’re probably not doing their job. Someone else will make an easier program that accomplishes the same task with less intrusions, and most users will love it.

A major rule of user interface design: “Every time you provide an option, you’re asking the user to make a decision.” That means users will have to think about something and decide about it. User’s option is not necessarily a bad thing, but, in general, you should always try to minimize the number of decisions that users have to make. This doesn’t mean eliminate all choice. There are enough choices that users will have to make anyway: the way their document will look, the way their web site will behave, or anything else that is integral to the work that the user is doing and really cares about.

Article: https://www.joelonsoftware.com/2000/04/12/choices/

The Process of Designing a Product

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about an approach of designing a software product that is “Activity Based Planning.” The main idea of this method is to figure out the activity that the user is doing and focus on making it easy to accomplish that activity. Some examples will show how to apply this approach in designing a product. First example, you’ve decided to make a web site that lets people create greeting cards. Using a somewhat naïve approach, you might come up with a list of features like this: Add text to card, Add picture to card, Get predesigned card from library, Send card (Using email or printing it out). This way of thinking would lead to a program that starts out with a blank card, with menu items for adding text, pictures, loading cards from a library, and sending cards. And then what the user is going to have to do is sit down and browse through the menus, trying to figure out all the commands available, and then do their own synthesis of how to put these atomic commands together to create a card. Now, with an approach of activity based planning, you need to come up with a list of activities that users might do. So, you talk to your potential users, and you come up with this “top three” list: Birthday Greeting, Party Invitation, and Anniversary Greeting. Now, instead of thinking about your program from programmer perspective (in terms of what features you need to have to make a card), you’re thinking about it like the user, in terms of, what activities is the user doing, specifically:

  1. Sending a birthday card
  2. Planning a party, and inviting people to it
  3. Sending an anniversary card

Suddenly, there are new ideas of designing. Instead of starting with a blank card, you might start with a menu like this:

What do you want to do?

  • Send a birthday card
  • Send an anniversary card
  • Send a party invitation
  • Start with a blank card

Suddenly users will find it much easier to get started with your program, without browsing around on the menus, since the program will virtually lead them through the steps to complete the activity. The three activities suggest some great features which you might want to add. For example, if you’re sending a birthday or anniversary card, you might want to be reminded next year to send a card to the same person, so you might add a checkbox that says “remind me next year”.

Activity based planning is even more important when you are working on version two of a product that people are already using. We should observe a sample of customers to see what they are using your program for and which activities they go with your program. We could add more activities to program or make existing activities more suitable to certain groups of customers. Therefore, activity based planning is helpful in the initial version of your application, where you have to make guesses about what people want to do, but it’s even more helpful when you’re planning the upgrade, because you understand what your customers are doing.

In conclusion, designing good software takes about six steps:

  1. Invent some users
  2. Figure out the important activities
  3. Figure out the user model— how the user will expect to accomplish those activities
  4. Sketch out the first draft of the design
  5. Iterate over your design again and again, making it easier and easier until it’s well within the capabilities of your imaginary users
  6. Watch real humans trying to use your software. Note the areas where people have trouble, which probably demonstrate areas where the program model isn’t matching the user model

 

Article: https://www.joelonsoftware.com/2000/05/09/the-process-of-designing-a-product/

Controlling Your Environment Makes You Happy

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about user interface programming for software. Most of the hard-core C++ programmers Joel knows hate user interface programming. This surprised him, because he found UI programming to be quintessentially easy, straightforward, and fun. It’s easy because you usually don’t need algorithms more sophisticated than how to center one rectangle in another. It’s straightforward because when you make a mistake, you immediately see it and can correct it. It’s fun, because the results of your work are immediately visible. You feel like you are sculpting the program directly. Most programmers’ fear of UI programming might come from their fear of doing UI design. They think that UI design is like graphics design, which is the mysterious process by artistic-minding people creates cool looking artistic stuff. Programmers see themselves as analytic, logical thinkers, being strong at reasoning, weak on artistic judgment. Therefore, they think they can’t do UI design. However, UI design is quite rational. It’s not a mysterious matter that requires a degree from an art school. There is a rational way to think about user interfaces with some simple, logical rules that you can apply anywhere to improve the interfaces of the programs you work on.

User interface interacts with users working with software. UI is important because it affects the feelings, emotions, and mood of users. If the UI is wrong and the user feels like they can’t control software, they literally will not be happy and they’ll blame it on software. If the UI is smart and things work the way the user expected them to work, they will be cheerful as they manage to accomplish small goals. So, UI must respond to the user in the way in which the user expected it to respond; other way the user is going to feel helpless and out of control. A psychological theory called Learned Helplessness, developed by Dr. Martin E. P. Seligman, is that a great deal of depression grows out of a feeling of helplessness: the feeling that you cannot control your environment. To make people happy, you have to let them feel like they are in control of their environment. To do this, the user interface needs to correctly interpret user’s actions.

The post gives us a thinking about designing and programming user interfaces for software. UI design should be considered as rational and logical process rather than a mysterious process that needs highly artistic judgment. UI must behave in a way that users feel like they are able to control the environment when they are using software. The cardinal axiom of all user interface design: “A user interface is well-designed when the program behaves exactly how the user thought it would.”

Article: https://www.joelonsoftware.com/2000/04/10/controlling-your-environment-makes-you-happy/

The Development Abstraction Layer

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the development abstraction layer that software developers work and are responsible for in a software business. The author started with the story of an experienced software developer who left a big software company to start his own business. He was confident that he could develop and sell software by himself because a lot of software products he worked on for the big company were sold pretty well to many customers. However, after months he could not get order from customer to support his own business and living cost. Finally, he had to come back to work for the previous company. He wondered why he failed with his own business. He was pretty sure that he lacked good marketing for his business. Marketing simply stands for everything in business of creating and selling software that he and many developers don’t understand all about. He was wrong. Software is a conversation, between the software developer and the user. However, that conversation requires a lot of work beyond the function of software development. It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.

Software developers design and write code, layout screens, debug, integrate, and they check things into the source code control repository. The level that a developer works at is called the development abstract layer, which is too abstract to support a business. The development abstraction layer needs an implementation layer — an organization with many support tasks – that takes their code and turns it into products to customers. The top priority of a software team manager is building the development abstraction layer that all developers only concentrate on and they don’t have to concern about other tasks.

The post gives us an idea of the scope of work that a typical software developer works for. A successful software company should have good support tasks across the board to help developers do their best and turn their works into quality products to customers. Moreover, if we plan to start a software business, we should understand which tasks we need beyond the development abstraction layer to keep our business running well.

Article: https://www.joelonsoftware.com/2006/04/11/the-development-abstraction-layer-2/