The world is moving with lightning speed in developing and refining processes and tools for things like deploying software essentially in real-time—the devops revolution, if you will. And great progress has also been made in areas such as building and modularizing and optimizing complex applications, or designing micro-service architectures. But such innovations do not seem to have reached the UI design world.

UI design, obviously, refers to the design of user interfaces, including both their visual and interactive/behavioral aspects. I am not talking about “graphic design”, of the sort involved in designing brochures, or posters, or even cool websites, for example. (The conflating of “graphic design” and “UI design” lies at the root of a lot of confusion and inefficiency in the design area. A lot of graphic designers think their great graphics skills automatically make them qualified UI designers, for example. Even otherwise knowledgeable executives hire graphic design teams when what they really wanted was UI designers.)

The problems with the UI design process as typically implemented are legion. Many designers, especially external ones, try to multi-task across projects, and so they never really develop the domain knowledge they would need to do a good job. Many designers coming from a graphics perspective view their work as being to create beautiful static designs, so they fail to think about (or document) how things will work, such as navigation. In the same spirit, many designers view each screen as a new “brochure” to let loose with the full range of their creative impulses on.

It’s also unfortunately quite rare to see designers who consider, or are open to feedback, on implementability, or who will even re-use UI paradigms that would save engineering time as well as make the user experience more uniform. The overwhelming majority of designers work in a ghetto of design-specific tools, giving rise to a huge amount of friction and conversion costs in realizing their designs in code. Recently they probably also use design-specific workflow tools, meaning everyone has yet another tool and login and process to remember and learn how to use. The majority of designers, it is safe to say, don’t really “get” agile or MVP. It’s common for them to view their designs as finished, pixel-perfect masterpieces.

What is even more alarming is the creeping takeover of the product management process by some over-ambitious designers, who claim that only they truly understand the user, and truly know what the user wants. They move beyond consulting on features to trying to take ownership of feature decisions. The irony of course is that in too many cases they actually understand the user more poorly than product managers, or product owners, or business folks, or even developers.

But wait. We have to have designs to look at and talk about and tweak so we know what we’re going to implement, right? And those designs have be conveyed in visual form somehow—like in Photoshop, right? And “management” wants to look at those designs, right?. And those designs also have to be shared somehow—like with some cloud-based design workflow system, right? That is the mentality we have grown to take for granted, and is what has led us into a design process which is heavily siloed in terms of tools and processes.

As a rough analogy, imagine that every computer program was mandated to first go through a “program design” phase, where the structure of the program—files, routines, classes, or even variables—was designed by a separate person or team, who were not themselves engineers but “program designers”, using a separate set of program design tools that had nothing to do with the technology that would eventually be used to implement the feature. Imagine that those program designs, using such program design tools, and shared using some program design cloud feature, were discussed and iterated on. And that only when the program design was finalized would a programmer then take the program design and convert it into an actual program, with very little of the design being directly re-usable in or convertible into the implementation. If during the course of implementation, it turned out that the design needed to be revised, of course only the most disciplined teams would take the time to go back and update the program design. So as a “bonus” for having this separate program design step, we would also end up with out-of-date program designs the first moment the design changed due to issues coming up during implementation, which in the best case would be a source of confusion. Imagine the inefficiencies inherent in such an approach.

I am not saying that we do not need to design; in the example I just gave, in fact time spent doing program design is often very well spent. What I am saying is that such program design, or UI design, should not occur in a vacuum, by a separate team of “experts”, who hand off their designs for implementation by someone else. The design work should be part and parcel of the development process, carried out by developers, in the broad sense. Others can consult and give input.

People talk about the need for UI prototypes and mock-ups, and systems for creating them. But actually, we already have a system for UI prototypes and mock-ups: it’s called HTML and CSS. Doing prototypes and mock-ups in HTML and CSS has huge advantages. First, we can take direct advantage of whatever libraries and standard styles we have already created in HTML and CSS. Such HTML/CSS prototypes are perfectly adequate—possibly even better than Photoshop mock-ups—for showing to management. Second, and perhaps more important, the prototype/mock-up becomes the starting point for a seamless process moving toward actual implementation. We don’t need separate cloud-based systems for storing and sharing these prototypes; they can be stored and shared like any HTML/CSS app. This is true agility; the prototype evolves naturally into the shipping product, with no chasms to jump over. Changes to the “style guide” are immediately reflected in both prototypes and implementation.

Of course this will require designers to learn HTML and CSS. They’ve already learned Photoshop, or Figma, or what have you. They can certainly learn another environment. But there’s another problem: in today’s world, HTML is not flat—it comes in the form of templates, with mixed-in logic, such as for loops, or conditions. Designers cannot write such template-like HTML, since they aren’t programmers, and they don’t know the structure of the data which will be populating the templates, and they don’t have harnesses which can drive the template with that data.

The answer is to have designers back off from actually creating screens at all. Instead, designers should position themselves as consultants. Instead of design being a waterfall-like preliminary to development, it becomes a consultative, parallel aspect of development. Designers provide initial input on the flow, such as “there could be five screens, to do A, B, C, D, and E.”. It goes without saying that the visual elements on these screens—fonts, colors, spacing—would be defined in an HTML/CSS-based style guide which already exists. So they don’t really have to specify these things at all. They’re already specified. The designers point out deviations from the style guide. They suggest visual optimizations and simplification. Thus they provide feedback on the prototype/mock-up implementation of the screens created by the developers, in iterative, agile fashion, helping evolve them seamlessly from prototype to production implementation.

In our agile, multi-disciplinary world, why are we still treating design as an island?

StackOverflow, the granddaddy of programming Q&A sites, has begun a long, inexorable decline into irrelevance.

I won’t talk here about how “StackOverflow sucks”; you can google that. Most of those people are complaining about how unfriendly SO is to newcomers. I don’t care about that. I actually think it should be more unfriendly to newcomers, who pollute and dilute the site’s content. I want to talk about the fundamental dysfunction on the site, the poor experience for the experienced users who should matter, and the failure in both developing and implementing the strategy, which over time is slowly and surely going to ensure its demise.

StackOverflow’s major business is selling eyeballs of people who come to it via Google. It cannot be a good sign for this would-be Unicorn, then, that all traffic metrics are flat to declining. Part of the problem is that virtually all programmers in the world already now come to SO to find answers to their questions. Even to continue at current levels assumes that Google will continue to drive traffic to the site. Indeed, at present for many programming questions, a Google query brings up half a dozen answers from Stack Overflow on the first page. This is both a blessing (now) and a curse (in the future); as Google’s algorithms evolve, it could easily start bringing up fewer SO results, and this is especially likely to happen as overall answer/question quality declines, as discussed later.

So the only remaining growth potential is more programmers, new domains, more questions (meaning more views per person), new content models, or new forms of monetization.

(more…)

Machine defeats man at the game of Go.

The entire world was stunned at the 4–1 win by Google’s Deep Mind over Lee Se-Dol, one of the world’s best Go players. Some say that Deep Mind is a highly specialized intelligence that only knows how to play Go. But the principles, techniques, and algorithms underlying Deep Mind do in fact have wider application to so-called AI-complete problems. What do they mean for Machine Translation (MT)?

The development of go programs and machine translation programs have followed a parallel path.

The initial generation of solutions to both problems were based on “classical” AI techniques of encoding human knowledge. The go programs used rules of “good shape”, and human-style “reading”. The MT programs used grammars and rulesets built by human linguists. The results, in the case of go, were programs which played at the amateur sub-dan level (meaning the top 10% of all players). The results, in the case of MT, were programs which could at best produce vaguely understandable translations.

(more…)

Branching sequences are common in real life. For instance, a recipe can be represented as a sequence of steps, with branches corresponding to variations. Games of go or chess , of course, are the classic example of branching sequences, where branches handle the “could have/should have played there” comments. Branching sequences can even be used to handle linear text , with branches used for optional or alternate material.

If we have complete control over the programming environment we can implement branching sequences in any way we want, most of them quite obvious. But in today’s web-based world, there are good reasons to represent such structures using XML (for transformations, interoperability, or even storage in XML databases) and HTML (for display). What is the best way to do so?

(more…)

According to a post to the computer-go mailing list, Tei Meikou 9-dan (pictured; GoBase bio), known for his expertise in computer go, characterized the Monte Carlo-style go program Crazy Stone (earlier post ) as “at least 1-dan”, based on its winning performance at the First UEC Cup Computer Go Tournament. This is a huge milestone. Tei characterized moves 86 and 88 as “almost professional level” (see SGF game record).

TechCrunch had an about why MySpace and Facebook are failing in Japan.

I had a glimmering of Facebook’s potential problems in Japan when I noticed that my son Ko was spending the great majority of his time online on Japanese social networking site . He even pays money for the service, although only a few dollars a month. Imagine how many Facebook subscribers would remain if they had to pay.

The reason given in the post for Facebook’s failure is its lack of cultural sensitivity and late entry. But the broader reason is simply hubris, or more kindly, a poor analysis of its real strengths and how to leverage them in Japan. (more…)

Welcome to the next generation of JavaScript! The ECMAScript Edition 4.0 (ES4)Working Group has been hard at work and on Oct. 22, 2007 put out an overview. Their proposals give new meaning to the concept of “kitchen sink” and “design by committee”. The only thing they forgot was to rename the language Javathon++. Luckily, ES4 is no more likely to take root than the previous abortive proposal issued in 2003.

(more…)

Why is everything Google makes so UGLY ?

Take your pick. Google Maps. Google Reader. iGoogle. GMail. Every single page is relentlessly, fixately UGLY .

(more…)

Feng-hsiung Hsu, one of the key contributors to Deep Blue (Wikipedia ) and now at Microsoft Research Asia, has published a manifesto proposing that go can be cracked by chess-like brute force techniques. Really?

(more…)

I just found out that Ted Nelson is continuing his decades-long, quixotic quest to reinvent the world’s basic document model, in the form of XanaduSpace 1.0, a recently released 3D document viewer that lets you see pan and zoom around a document universe with the transclusive relationships between documents represented as colored beams. You can download it here. This version is very close to demoware: there’s just one set of sample documents to be viewed.

(more…)