The Stripy Strudel's Journal

It's well known that while the population of the planet grows, the total IQ stays the same. This applies to Internet users, too. As the number of users grows, the average intelligence plummets, and the software has to adapt. Let's continue the trend into the future and imagine what the browser will be like in, say, 2030. Increase this if you're optimistic, decrease if you're pessimistic.



After numerous improvements aimed at achieving user-friendliness, the browser has become as simple as it can be. It has no menus (neither main nor context), no toolbars with many buttons, no sidebars, no status bar, no dialog windows with settings. All of this was too complex for most users anyway, and scared the poor average Joe away from computers. The future browser will hardly be do a tenth of what today's browsers can do, but it will finally be usable by everyone. Speaking about visual appearance, shadows and rounded corners will still be in fashion. Thanks to the lack of any text in the interface, the browser doesn't need translation.

A browser ships with the operating system, an operating system ships with the computer. A regular user has no reason to change any of these, so the only choice among competing products that he makes is when buying a computer. This choice determines both the operating system and the browser. The browser doesn't even have a name because it's not a separately marketed product. The browser window lacks a title bar because nobody cares about the name of the program. The only button pertaining to the window itself is the red close button, and even that one looks superfluous. The window always has standard size, and web pages are usually designed for that size. Saving of pages and images as well as opening of local files is accomplished by dragging between the browser and the file manager, and printing is done by dragging to the printer.

At the top of the window is a universal field that combines an address bar, a security indicator, a window title bar and a search field. The URL is technical information uninteresting to the user; they only care on what website and what page they are. The website name is automatically verified through its certificate. The only security indication is the color of this bar: green means OK, red means problem. The user can't be expected to know about SSL or domain names, and judging whether the web page is safe enough has to be the browser's job. When it's unsafe, the main working area turns red as well because it's not easy to draw the user's attention. When the bar is clicked, it becomes white and empty, and the user can type in it. The text is always looked up in the search engine (the one with which the browser vendor has made an agreement). If an eccentric user types a URL (where would he get one in the first place?), it will work, too.

To the left of the universal field is the Back button. Its size makes it easy to find. To the right there's a button that changes its function. Usually it's Reload, but during loading it turns into a Stop button (red “No entry” sign), and while typing in the bar it's Go (green right arrow). There's no progress indicator. Instead, while the page is loading, the incomplete document isn't rendered, and the main area displays a “loading” animation instead. It's better to not render incomplete documents because their strange behavior confuses users. Fortunately, thanks to future technologies, loading will rarely take long. There are no scrollbars, either; to scroll, one grabs any part of the page that isn't a link and drags. To find text within the current page, it's enough to start typing.

The bottom part of the window contains eight slots replacing both tabs and bookmarks. Technically they're closer to tabs: each of the eight slots is like a separate browser window with its own navigation history. Clicking a slot activates it, dragging reorders, and dragging a link to an inactive slot opens the link in that slot. The active slot is marked with a contour as well as with the arrow-like shape of the main area. There are always eight slots, you can't add or remove one. A regular user doesn't need more than eight, and the controls for adding, removing and scrolling them would add unnecessary complexity. On the first start, the slots are filled with recommended popular websites, and on subsequent starts they keep their content as well as navigation history. This way, they also replace bookmarks: you can simply keep a frequently visited website in one of the slots.

For the future user, pictures are so much better than text, that's why the slots display website logos. For older websites, heuristics will be used to detect where the logo is on the page, while modern sites will be able to take advantage of the new API. The API will allow the page to tell the browser what exactly should be shown in the slot, and even update that dynamically. In the figure, Google shows the search text and the number of hits, LiveJournal shows the name of the user whose journal is open, and Gmail shows the number of unread messages; the latter keeps updating even in an inactive slot.

The split percent users who aren't satisfied with this functionality will be part of a community going further and further away from the mass market. They will have their own browsers and operating systems. Some of those who develop web services for the mass market will be parts of that community, but most webmasters will use rapid visual development tools close in spirit to the “folk's” browser.

The Russian version of this entry (see link below) features a poll. I have included English translations in the poll and encourage all readers to participate. You'll need to register a free LiveJournal account to vote.

По-русски: Минимум необходимого

From all the features of my PDA, I only use two; all the others have turned out to be useless or unusable. Firstly, I read books with Haali Reader; secondly, I use the to-do list, but only to keep the shopping list for the supermarket.

The look of this to-do list is trivial: there is a list with a square to the left of each line; the square can contain a check mark. This simple application also has a menu where I should point out two items:

• Active tasks
• Completed tasks

Obviously, tasks are subdivided into active and complete. Initially, I can see both kinds in the list. If I pick “Active tasks” in the menu, I'll only see the active tasks, and when I open the menu next time, there will be a check mark to the left of the “Active tasks” item. So I can only see active tasks (I've enabled this mode a year ago and have already forgotten what I did to get there), and now I want to see all the tasks. Question: what should I pick in the menu?

Here is how I think: “Right now I can only see active tasks, and the ‘Active tasks’ menu item is checked. I cannot see any completed tasks, and the ‘Completed tasks’ item is unchecked. It seems like the categories of tasks currently shown have check marks in the menu. In addition to the active tasks that I already see, I also want to see the completed tasks, so I need the ‘Completed tasks’ menu item to have a check mark. Usually, when I want a check mark to appear for a menu item, I have to click the item.” Of course, I make a decision like this rather intuitively, but it is actually backed by reasoning like this.

After considering this for a second, I pick “Completed tasks” in the menu, and what I get is… the list of only the completed tasks! After that, the “Completed tasks” menu item has a check mark, but the “Active tasks” item hasn't. At a second attempt, I realize that, in order to see all the tasks, I have to remove the check mark from the menu item that has it, which returns the system to the “normal” state (as opposed to the “special” modes where only active or only completed tasks are shown).

Of course, I'm long used to such behavior of this application, but I've never understood it and have rather memorized the “irregularity”, just like I had to remember that the marks for cold and hot water in my bathroom are switched. Every time I use the tap, I routinely recall, “The wrong way!” and tilt it to the side marked with red to get cold water. Similarly, every time I use the menu in the to-do list application, I recall that it works “the wrong way”.

Earlier, when I encountered such interface solutions working “the wrong way”, I thought them to be bugs or design mistakes. However, mistakes of this kind are quite common and are often similar to each other, fitting in a pattern. Moreover, such solutions are often found in applications and devices that non-technical users usually describe as simple, intuitive, easy and convenient to use. It seems like there are two approaches to interface between a human and a machine, and maybe even two systems of thinking. I might not have chosen the best names for them, and someone might have already described and studied them, but nevertheless I'll try to provide brief descriptions.

Object-oriented approach

This approach is often found in technical experts, especially programmers. The approach is centered around the notion of an object (such as a document or the system as whole). An object can be in one of a multitude of states, and it transitions from one state to another under influence of various factors, including user actions. In order to control the object, it's important to know its current state, that's why this approach great attention is paid to informativeness of the interface, that is, to its ability to inform the user about the current states of objects. The problem the user is facing is perceived as the difference between the current and the desired states of the system, and is solved by applying the inputs necessary to get the system into the desired state. To solve a problem successfully, one has to understand the structure of the system, its possible states and the transitions between them, that's why the object-oriented approach favors documentation that describes concepts, principles and the overall system organization.

Procedure-oriented approach

This approach is prevalent in people who aren't technical experts. The approach is centered around the notion of a task. In order for a problem to be solved, it has to match one of the tasks that the application or device is designed for (ideally), or at least to be possible to break up into a sequence of such tasks. The problem is solved by applying the inputs that get the system to produce the desired result. That's why the procedure-oriented approach favors documentation that provides step-by-step instructions for solving typical problems. Because the critical part is knowing what input is necessary to perform a task, attention is paid to discoverability of these inputs (toolbars, context hints).

It's hard for me to write about the procedure-oriented approach because it's not how I think, and everything that's made that way feels unnatural to me. The conclusions I'm making are based not on my personal experience from using this approach but rather on the analysis of the systems following it.

I'm surprised not by the very existence of two different approaches, but rather by the gap between them that is so wide that people following one of them can't even project the thoughts of those following the other approach onto themselves. The existence of these two approaches answers a lot of questions:

• Why cannot programmers design a good interface for non-programmers?
• Why do televisions and videotape recorders have such “stupid” menus that an experienced programmer often cannot configure them without the manual?
• Why are the “easy to use” image processing applications (that often come along on a CD with a scanner or a digital camera) unusable?
• Why don't you have to press “Enter” on a doorbell after entering a one-, two-, or three-digit apartment number?
• Why do home appliances so often have those (annoying to many programmers) automatic transitions from one state to another after a delay?
• Why cannot many people master programming?

On the other hand, new questions arise:

• Is the bias towards one of the two approaches inborn or is it rather acquired with upbringing?
• Can a person following one of the approaches learn to use the other one?
• Does schooling affect the choice of approach?
• Does the object-oriented approach determine the choice in favor of a technical occupation, or is it the other way round?

The original entry in Russian features a poll: Object-oriented vs. procedure-oriented approach. It is possible to vote in the poll after logging in to LiveJournal; registration of LiveJournal accounts is free.

Which of the approaches better describes your way of thinking?

• Object-oriented approach.
• Procedure-oriented approach.
• A third approach not described here (please comment).
• The subdivision into the two approaches is fundamentally flawed (please comment).

Please don't vote if you haven't read all of the above. Also don't vote and accept my apologies if you regard asking the question inappropriate.

UPDATE: I have to agree with kalinka_malinka. This entry is an example of how to run knowingly non-representative surveys.

UPDATE: Another interesting aspect of the problem (in Russian).

По-русски: Все программисты с Марса, все пользователи с Венеры

According to a story of unknown credibility, on the border of the 19th and 20th centuries investors considered automobile to be economically hopeless. Nevertheless, Henry Ford had managed to obtain a credit of $1400 to build automobile construction under very tight conditions. It seemed that the revenue from car sales wouldn't be able to cover the investment within the term for which Ford could get the credit. Henry Ford might never have become the man who made automobile available for millions of people — if not for the idea, brilliant in its economical efficiency, that came to his mind. The idea was to produce cars deliberately less reliable than it was possible, and to make money by selling spare parts. A quote attributed to Ford: “I make cars to sell parts for them”. The new business model let Ford build a profitable enterprise, return the credit in time, and become the world's first mass producer of cars.

Ford brought much to both industry and society. For example, the modern 40-hours week and the very notion of “weekend” became de-facto standard after having been implemented at Ford Motor Company. However, one of his innovations, namely “to make a worse product than you can when it's economically justified”, gave the world a dubious gain. Of course, if not for Ford, someone else would have come up with this idea, great in its simplicity; or maybe someone already had implemented it before him. Today you can see live examples of this wherever you look, and it's time to think about the reasons and consequences of this phenomenon.

It's important to note the difference between production of goods or services of simply low quality and production with quality deliberately lower than the producer is capable of ensuring. For example, a software producer who releases software with bugs doesn't necessarily fall into this category because it's impossible to get rid of all bugs (moreover, it's possible than the capabilities of this producer are so limited that they can't make less than one bug per ten lines of code, or that the programmer does a bad job because he's underpaid). We are more interested in a producer who releases software without sufficient debugging in order to make money on paid support or upgrades. So what are the reasons that can make it economically justified to make deliberately worse products than it's possible?

• Releasing unreliable products stimulates demand for add-on goods or services (spare parts, repairs, tech support).
• Short life of the product stimulates demand for more units in replacement of broken or worn out ones.
• Low prime cost of a low-quality product allows to bring the consumer prices down and obtain greater revenue by entering the mass market.
• Low-quality goods are possible to produce faster or in larger quantities, which leads to competitive advantage over those who make quality goods.
• In the modern market, quality is no more the primary tool of competition, inferior to, for example, efficient advertising.
• The market has come to a situation where, for the above reasons, all the competitors release low-quality products; under such conditions it doesn't make sense to try to achieve better quality in this branch because the consumer will have to choose among the available offers anyway.

It's hard to say whether it's good or bad that Henry Ford's approach is widely implemented in modern industry. Of course, many consumer products, such as cars, we'd never have seen without it, or they would be elite goods available to just a few. On the other hand, the lowering of quality directly affects the consumer. It's especially prominent due to the last reason in the list: as a chain reaction, it impels the makers to skimp on quality more and more in order to gain competitive advantage by other means (low prices, high volumes, advertising). Competition based on “who makes better” seems to have been left out of the modern economy and survived only in particular branches with very specific markets.

Each one of us is both a producer and a consumer. At work, we take part in production of goods or services, the rest of the time we consume what others produce. As a consumer, everyone is, of course, interested in having quality goods, however, as a producer, one might find it profitable to skimp on quality. Obviously, a single person's attitude towards quality can be contrastingly different when they routinely switch between the two roles. This means that there must be a conflict point somewhere where two approaches meet. In my opinion, there are three possible models for a person's attitude towards quality:

1. One can accept that most of what one consumes is of low quality, just like what one produces.
2. One can have double standards and expect high quality goods from the market while making low-quality production.
3. Finally, one can demand quality of the goods offered and have the same attitude towards one's own output.

It's worth noting that an employee who follows the third model is inevitably in explicit or, more commonly, implicit conflict with the employer who strives to save on quality.

I must say I'm of the third kind. The second model I can't fit in my head at all, and for the first one I'm probably too old-fashioned. Having done some creative work well brings me direct æsthetic satisfaction, and it's for this satisfaction that I'm working in this particular branch and at this particular enterprise. Recently I've turned down an offer of a significantly higher salary elsewhere for a job that I could do but which was completely uninteresting to me. Having taken this decision, I've realized that I don't only work for money; an important part of what I get from my work is the very æsthetic satisfaction that I wouldn't have if I did a worse job than I can in favor of, say, production rate. This means that my and my employer's goals are unfortunately different: I squeeze the maximum æsthetic pleasure from my job by doing it as well as I can, while the employer strives for tighter timeframes, higher volume and everything else but quality. This conflict of interest is currently implicit. If it becomes explicit, I'll have to change my job.

The original entry in Russian features a poll: How do you combine the two attitudes towards quality?. It is possible to vote in the poll after logging in to LiveJournal; registration of LiveJournal accounts is free.

How do you combine the two attitudes towards quality?

• Model 1.
• Model 2.
• Model 3.
• A totally different model (please comment).
• I don't face this problem (please comment).

Please don't vote if you haven't read all of the above.

По-русски: XXI век: прощай, качество?