This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about designing social interface which is the next level of software design issues, after you’ve got the UI right, designing the social interface. Software in the 1980s, when usability was invented, was all about computer-human interaction. A lot of software still is. But the Internet requires a new kind of software: software that’s about human-human interaction such as discussion groups, social networking and online classifieds. It’s all software that mediates between people, not between the human and the computer.

When you’re writing software that mediates between people, after you get the usability right, you have to get the social interface right. The social interface is more important because the best UI software would fail with an awkward social interface. More, let’s look at an example of successful social interface. Many humans are less inhibited when they’re typing than when they are speaking face-to-face. Teenagers are less shy with cellphone text messages, they’re more likely to ask each other out on dates. That genre of software was so successful socially that it’s radically improving millions of people’s love lives (or at least their social calendars). Even though text messaging has a ghastly user interface (just being a little bit improved recently), it became extremely popular with the kids. The joke of it is that there’s a much better user interface built into every cellphone for human to human communication: this clever thing called “phone calls.” It is so simple that to dial a number, and after that everything you say can be heard by the other person, and vice versa. However, many people choose the way that you break your thumbs typing huge strings of numbers just to say “damn you’re hot.” Clearly, it more awkward to say this than texting!

In designing social interface, you have to look at sociology and anthropology. In societies, there are freeloaders, scammers, and other miscreants. In social software, there will be people who try to abuse the software for their own profit at the expense of the rest of the society. Whereas the goal of user interface design is to help the user succeed, the goal of social interface design is to help the society succeed, even if sometimes it means one user has to fail.

Social interface has rapidly grown and developed together with social networking. Software companies hire people trained as anthropologists and ethnographers to work on social interface design. Instead of building usability labs, they’ll go out into the field or online space and write ethnography.

Article: https://www.joelonsoftware.com/2004/09/06/its-not-just-usability/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about his sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes. The test form is:

“The Joel Test

1. Do you use source control?
2. Can you make a build in one step?
3. Do you make daily builds?
4. Do you have a bug database?
5. Do you fix bugs before writing new code?
6. Do you have an up-to-date schedule?
7. Do you have a spec?
8. Do programmers have quiet working conditions?
9. Do you use the best tools money can buy?
10. Do you have testers?
11. Do new candidates write code during their interview?
12. Do you do hallway usability testing?”

The Joel Test is so easy that to get a quick yes or no to each of the 12 questions. You don’t have to figure out lines-of-code-per-day or average-bugs-per-inflection-point. Give your team 1 point for each “yes” answer. However, please remember that you really shouldn’t use The Joel Test to make sure some formal or important things like your nuclear power plant software is safe. A score of 12 is perfect, 11 is tolerable, but 10 or lower and you’ve got serious problems. The truth is that most software organizations are running with a score of 2 or 3, and they need serious help, because companies like Microsoft run at 12 full-time. Certainly, these are not the only factors that determine success or failure. For example, you would not want a great software team working on a product that nobody wants. In contrast, it’s possible to imagine a team of “gunslingers” that doesn’t do any of this stuff that still manages to produce incredible software that changes the world. However, everything often has meaning itself, so, if a team gets these 12 things right, you’ll have a disciplined team that can consistently deliver.

The test addresses generally practical issues that a software team almost needs to work productively in building and testing software products that are feasible to get into market. The issues spread from tools and control to the working environment and habits for typical software team. The technology and environment have rapidly changed over time, but the issues mentioned in The Joe Test are still helpful.

Article: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-steps-to-better-code/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the term “user model”, “program model”, and making program model conform user model in a program. User model is users’ mental understanding of what the program is doing for them. When a new user starts using a program, they do not come with a completely clean slate. They have some expectations of how the program is going to work. If they’ve used similar software before, they will think it’s going to work like that other software. If they’ve used any software before, they are going to think that your software conforms to certain common conventions. They may have intelligent guesses about how the UI is going to work. Similarly, program model that is a program’s “mental model” is encoded in bits and will be executed faithfully by the CPU. If the program model corresponds to the user model, you have a successful user interface.

For example, in Microsoft Word (and most word processors), when you put a picture in your document, the picture is actually embedded in the same file as the document itself. After inserting the picture in the document, you can delete the original picture file while the picture will remain in the document. On the contrary, HTML doesn’t let you do this, HTML documents must store their pictures in a separate file. If you take a user who is used to word processors, and doesn’t know anything about HTML, and sit them down in front of a HTML editor like FrontPage, they will almost certainly think that the picture is going to be stored in the file. This is a user model. Therefore, program user (the picture must be in a separate file) does not conform user model (the picture will be embedded)

If you’re designing a program like FrontPage, you have to create something to bring the program model in line with the user model. You have two choices: changing user model or program model. It looks remarkably hard to change the user model. You could explain things in the manual or pop up a little dialog box explaining that the image file won’t be embedded. However, they are inefficient because of annoying and users not reading them. So, the best choice is almost always going to be to change the program model, not the user model. Perhaps when they insert the picture, you could make a copy of the picture in a subdirectory beneath the document file.

You can find user model in certain circumstances by asking some users what they think is happening after you describe the situation. Then, you figure out what they expect. The popular choice is the best user model, and it’s up to you to make the program model match it. Actually, you do not have to test on too many users or have a formal usability lab. In some cases, only five or six users next to you are enough because after that, you start seeing the same results again and again, and any additional users are just a waste of time. User models aren’t very complex. When people have to guess how a program is going to work, they tend to guess simple things, rather than complicated things.

It’s hard enough to make the program model conform to the user model when the models are simple. When the models become complex, it’s even getting harder. So, you should pick the simplest possible model.

Article: https://www.joelonsoftware.com/2000/04/11/figuring-out-what-they-expected/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

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/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

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/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

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/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.

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/

From the blog CS@Worcester – ThanhTruong by ttruong9 and used with permission of the author. All other rights reserved by the author.