UI Design in 2018

April 20th, 2018

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?

Insecurity as the root of sexual predation

December 18th, 2017

The world is undergoing a (welcome) sea change as it comes to be receptive to reports of, and broadly condemn, sexual misconduct in the broad sense, ranging from crude jokes, to unwanted sexual approaches, to touching and groping, all the way to rape.

There seems to be a consensus that the root of such behaviors lies in power issues. In other words, at least when it comes to active sexual predation, the offenders are acting, according to this consensus, not out of sexual desire, but rather as a way to assert their power. Rape as an expression of power is certainly a useful insight; for example, marauding armies commonly rape women as a way to assert their dominance over the societies they just conquered. But is this explanation really completely adequate, and does it really apply to all cases? Was Kevin Spacey, in a drunken stupor at age 26, really attempting to prove his power over the teenager he allegedly threw on a bed and laid on top of, or did he just want to get laid?

I am no student of sexual behavior or gender relations. I defer to all those with deeper insights on the subject, including on the topic of why the dozens, or hundreds, of men, who have been found to engage in repulsive sexual behaviors of varying levels of severity, did as they did. I intend to continue to study and learn; for example, would learned commentators assert that George H. W. Bush was engaging in power-based sexually predatory behavior when, at age 90, he grabbed the rear of the women standing next to him in his wheelchair?

I have a different theory–that some or much of the behavior is related to sexual insecurity, and an attempt to compensate for it.

Harvey Weinstein was not, in this theory, exerting his power over the women he invited up to his hotel suite and pathetically asked for massages. Rather, he was desperately trying to find some woman who would validate his attractiveness and desirability, which he himself seriously doubted, and probably had all his life. My guess is that he had never had a single satisfying sexual relationship, including with his wife. That could well have been due to personality defects which made him a poor lover, but that’s not really the point, which is that he was not just horny; it that were the case, he could have hired call girls. He was not just eager to prove his power; if that were the case, he could have fired someone, or rejected some script. Instead, he was desperate to validate his desirability in the form of finding anyone who would agree to have sex with him, and in the process egregiously misinterpreted the notion of “agreement” in extremely loose fashion, to include cases where the actress in question “agreed” in order to preserve or promote her career.

In saying that Weinstein was motivated not by power, or by sexual desire, but by insecurity and the need for validation, I am not attempting to justify his despicable behavior in any way, shape or form. But as we as a society go about trying to understand and deal with the men we have been finding have long histories of serious sexual misbehavior, perhaps the insight that such behaviors may have at least some of their roots in lifelong insecurity could prove of value.

Consciousness of consciousness

January 3rd, 2017

Everyone seems to pretty much agree that consciousness is a big mystery, and a really important one. Careers have been built, and books written, on the topic.

Of course, no one really agrees on what consciousness means. Is an animal recognizing itself in a mirror a form of consciousness? Others seem to confuse consciousness with thought. Is consciousness somehow related to emotion, such as what we feel when viewing a beautiful sunset? Is consciousness related to the elusive notion of qualia–what it means for something to be “red”, for example? Or is consciousness what distinguishes human beings from lower life forms–we are conscious, and they are not? Is consciousness merely the quality of being conscious (assuming we can define that), or something more? Is consciousness connected to, or identical with, the values we associate with humanity, such as ethics, or love, or loyalty? Is consciousness a state, or a process? Ultimately, in our discussions of consciousness we are trapped in an infinite loop: we don’t know what consciousness is, so we cannot speak coherently about it or what mechanisms it might be based on, and without knowing the mechanisms it is based on, we cannot define it.

To me, it makes no sense when talking about consciousness to say I’m conscious of having a headache. I just have a headache. It make no sense to say I’m conscious of seeing a chair. I just see a chair. It makes no sense to say I’m conscious of a beautiful sunset; it’s just a beautiful sunset. The term consciousness is vacuous if we use it to refer to any experience whatsoever. To be  worth talking about, consciousness must have a subject. For purposes of this discussion, we will say that the subject is an experience. Consciousness is not merely having the experience; it is a higher-level mental process whose subject is the having of the experience. By “experience” I mean something that we think, or sense, or feel. If one chooses to consider thoughts, and senses, and feelings, as neurological processes, then by this definition consciousness is a higher-level mental process whose subject is neurological processes. Since a mental process is itself a neurological process, it follows that consciousness is best defined as a neurological process the topic of which is a neurological process. Expressing this way makes the recursive nature of consciousness clear: we are conscious, but also can be conscious of being conscious, and conscious of being conscious of being conscious, and so on ad infinitum. To make it clear, this can be called reflective consciousness.

Read the rest of this entry »

The acid-head who thought he could fly

August 23rd, 2016

hqdefault

Let’s assume someone, perhaps under the influence of LSD, believes he can fly–or perhaps (he believes) God has told him he can fly–and so he jumps off a building intending to fly away. But instead he falls to the ground and dies. The reason is that his belief was incorrect; it was counter-factual. It did not conform to reality, or at least to a certain subset of known physical reality.

Now I’m well aware that the notion of “fact” is a slippery thing and there are many kind of beliefs and worldviews and mindsets that do not fall as cleanly onto the spectrum of fact vs. fiction as the belief that you can fly. However, one can stipulate that not all propositions in the world are necessarily characterizable as provable facts without abandoning the claim that some facts, physical or otherwise, do in fact hold.

Read the rest of this entry »

StackOverflow: the fatal flaw in its strategy

June 5th, 2016

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.

Read the rest of this entry »

How to piss away $8M in venture funding

May 3rd, 2016

Following Tolstoy, “All successful startups are alike; each failed startup fails in its own way.” Some startups fail because of flawed product execution. Some fail because of poor marketing. Some fail because they can’t get the right people. Some fail because they run out of money. Some fail because they did not understand the marketplace and the competition.

This story is about an anonymous company that failed for a relatively unique reason: a yawning gap between vision and product concept.

You might think that vision already implies a product concept. Yet actually the same vision can be realized via many product concepts. This particular company’s vision was to automate enterprise knowledge management and distribution. A wonderful vision, but one which could take the form of many different product concepts. For instance, one concept would be to build a monolithic, closed, smart knowledge management system. A very different concept would be to build smart knowledge management widgets that fit into and complement existing knowledge/content management approaches.

Read the rest of this entry »

AlphaGo: Implications for Machine Translation

April 7th, 2016

In this March 15, 2016 photo, South Korean professional Go player Lee Sedol reviews the match after finishing the final match of the Google DeepMind Challenge Match against Google's artificial intelligence program, AlphaGo, in Seoul, South Korea. Google's Go-playing computer program again defeated its human opponent in a final match on Tuesday that sealed its 4:1 victory. (AP Photo/Lee Jin-man, File)

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.

Read the rest of this entry »

Mobile Phone Localization in India

March 20th, 2016

languagepanelThe Telecom Regulatory Authority of India (TRAI) is proposing, as part of the government’s Digital India push, to make regional language interface capability mandatory on feature phones. These standards are expected to go into effect in six months.

One of the world’s leading localization companies, Moravia, has weighed in with a blog post entitled “India Gets Serious about Mobile Phone Localization“. Unfortunately, this post reveals a fundamental confusion about almost every aspect of this situation: the difference between feature phones vs. smart phones, between language support on phones themselves vs. applications, and between localization of interface vs. content. The post says that India is:

already one of the fastest-growing smartphone markets in the world, and the second largest overall. India’s vast hinterland is smartphone-equipped and hungry for local language content. The communities are cash-rich, and India’s e-commerce companies will have to reach out to them in earnest if they want to stay in the game.

this single paragraph neatly encapsulating all the confusion.

Read the rest of this entry »

The Elusive Uberization of Translation

January 1st, 2016

The title of this post is borrowed shamelessly from the excellent article by Florian Faes found here.

Over the last decade, I’ve lost track of the number of times that the translation industry was gonig to be “reinvented” by this that or the other new model, usually one based on some sort of new technology. And each “reinvention” is accompanied by breathless hype and wonder in more blogs and posts by industry “experts” than you can count, many of whom should know better. Each “reinvention” is based on some plausible-sounding theory about the nature of the translation market that turns out to be just wrong.

These false theories and assumptions have no end. There would be an infinite demand for translation if only it were cheaper. There would be an infinite supply of translators if only we could tap the millions of bilingual people our there. Or no, the real problem is the efficiency of translation tools. Machine translation (MT) will eventually take over the lion’s share of translation work. Or it won’t. What we really need is to make it easier to order translation; where is my one-click translation button?

Problem is, none of these assumptions have proven to be true. The largest translation companies in the world continue to derive most of their revenue from large contracts with enterprises that have ongoing needs for translated documentation and software, carried out via well-defined processes and requiring well-defined quality levels. Startups based on the latest idea for a shiny new translation gadget flounder, ending up doing down-rounds to keep the lights on. Mid-tier translation companies continue to dominate the business in revenue terms, most doing semi-specialized medium-sized projects for medium-sized clients.

So how do we uberize this? The fundamental problem is to what extent translation is a commodity. Ride-hailing is the ultimate commodity: a car comes and takes you from point A to point B. There may be different sizes of cars, or special services like handicapped accessibility, but these amount to nothing more than different grades of coal. Ride-hailing is commoditizable because it is a commodity. We can aggregate demand, aggregate supply, and then tweak the economics of the business to death. To speak of uberizing translation implies that translation is a commodity.

Read the rest of this entry »

Beliefs about belief

December 13th, 2015

Last night I went to a dinner party. One guest was talking about how different people believe different things and that’s just how it is and that’s fine. According to her, it’s all about diversity, and tolerance, and acceptance, and realizing that different people have every right to form their own opinions. 

That sounds unassailably correct until you think harder about it and realize that it’s not. I pointed to a tree outside the window and asked her if she thought it was OK for a person to believe that the tree was not actually there. Somewhat trapped, she asserted that yes, it would indeed be OK. After all, it could be me that was hallucinating the existence of the tree. Perhaps the person is living in a parallel universe where the tree does not in fact exist. Perhaps the tree is a hologram.

The problem with this line of thought is that beliefs have consequences. If I go out and pick an apple from the “non-existent” tree and bring it into the house and ask the person to take a bite, they will be hard-pressed to deny that they are biting into a real apple. If the “non-existent” tree is blown over by strong winds and crashes into the roof of the house, the damage will be very real no matter what the person believed about the existence of the tree. Or if I am standing on the roof of a building and believe that I can fly and decide to therefore jump off, I will die. If I believe that global warming is not caused by humans, and thus choose to take no action, the Marshall Islands will eventually disappear into the ocean.

Read the rest of this entry »