Data Design

(This was originally published in For 100 of Our Closest Friends, Volume One.)

When designers talk about their process, they often talk about things like sketching and wireframing and usability tests. But it has recently occurred to me that this is not what I usually start out with. The first thing I typically design is the application’s data model.

What kinds of things are there in the application? What properties do the things have? How are they related to each other? Can we normalize this structure, make it simpler?

If the application grows, can this model accommodate the changes?

Recently, I had a very preliminary design meeting about a website that would help people organize soccer matches. This seems like a simple kind of application. You probably have users and teams and matches. Users belong to teams, and teams participate in matches. Well, you probably also need to have events, if there are several matches at the same event.

But wait, if you have events, doesn’t that mean that you might not know all of an event’s matches beforehand? Maybe the event has some kind of run-off system where the winners of a set of matches play against each other, so the participants of that match aren’t known in advance. Okay, let’s drop that for now, but still try to design the system so that we might be able to support something like this at a later date.

So a typical use case would be for an organizer of an event to create a new event, add some matches, add teams to the matches, and add players to the teams. But some teams probably already exist in the system; perhaps the teams recreated their own teams in-system. Wait, we probably need to let players create their own accounts. But if they do that, can they choose which teams they want to belong to?

Or can only team creators invite players to teams? What if a player isn’t yet in the system, but the person who created a team added the player to the team anyway… we need to support something like this, but can the player then claim the spot in the team? What if different people added the same person to different teams, each creating their own player; can the person then consolidate these things into their canonical account?

All of these questions come down to model design. What are the basic entities in the system? How do they relate to each other?

This is often the first thing I think about when designing an application. You might think that it’s not really a designer’s job to do that; let the programmers deal with that stuff. You’d be wrong. The model fundamentally defines how an application behaves, what kinds of features it can support. If your model is an afterthought, if it’s inconsistent with the user interface, your application will never work right.

Start out with the model, and keep it in sight during the whole design process. Don’t let programmers take it over. It’s part of your job.

Further Reading

Nick Disabato:

There are a million small experiential ramifications for your data model, and it’s the death of a thousand cuts if you aren’t thinking of them from day zero.

Johannes Thones:

By looking at the UI, you should not be able to see already the data structure. The UI should be solely tailored to be easy to perceive and understand by the user. Users don’t think in data structures typically – don’t make them. (…) With the former rule at hand, some of us engineers tend to go out, design a view and make the data structure look exactly the same. This it not how it is supposed to be. We have layers in all of our applications to abstract away the data structure, for example in the database, from the user interface. So we should do it. Design the data structure to be efficient and elegant for storing. Not like in the user interface.

I think this is true for systems where you have no control over the data model; in those cases, you need to be careful not to fall into the trap of letting the existing data model dictate the user interface.1

But the simple fact is that the data model does govern what the UI can do. If we’re coming at this from the point of view of a frontend designer who has to turn a poorly designed backend into a human-friendly user experience, we’re already starting out on the losing side.

I think the conclusion we should draw from this is the following: having a backend engineer design the data model, and then trying to build a UI on top of it, is backwards. It should be the other way around. We need to design our data structures such that they support the kinds of UIs we want to provide, and such that they are flexible enough to support different kinds of UIs in the future.

This doesn’t mean that we should always store data denormalized, or store it exactly in the way it’s shown in the UI. It mustn’t even mean that UX designers need to become data model experts, and spend their time attending database design classes (although that might be helpful). Instead, it can simply mean that we should do at least some basic UX design work first, and derive data model requirements from that.


  1. I.e. allowing the UI model to be dictated by the implementation model at the expense of the user’s actual mental model of how your software works. back

If you require a short url to link to this article, please use http://ignco.de/715

Competition and Partisanship

While writing about window management in iOS, and comparing it to what Microsoft had done in Windows 8, it occurred to me that we truly live in amazing times. The fact that three different companies are giving each other a run for their money on OS design is fantastic for people who actually use these devices. I’m growing more and more tired of the partisan reporting that happens in the tech industry, where people pledge allegiance to one or the other multinational corporation and support everything that corporation does, while automatically dismissing and belittling everything everybody else does, particularly if other companies copy features from the one company they like.1

This type of jingoistic support for one’s chosen platform, combined with acerbic, often sarcastic dismissal of the competition, helps nobody — not even the company being supported. That company would be better off if its own users provided honest feedback on its shortcomings, not fawning, thoughtless support.

Indeed, people who buy Apple products should be ecstatic that Microsoft and Google are competing with Apple, and vice-versa.2 Everybody should be happy if each company takes each other company’s greatest ideas, and improves upon them. The last thing we want is another 90s-type situation, where one company controls 95% of the market, and as a direct result, progress just halts for a decade.

I’m really hoping that we’re not living through another Amiga/Atari era, were we have a bit of competition for a few years, but eventually, some companies die, others fade into irrelevance, and one company ends up owning most of the market.

In fact, I wish we’d see even more competition! I wish Samsung would get serious with its own OS. I wish HP would revive Web OS. I wish Blackberry would stop making bad decisions, and start kicking ass again. I wish smaller companies like Jolla, Ubuntu, and the Firefox OS team would be better able to compete with the big guys. I wish Microsoft would get more credit for the progress it has made in UI design, instead of just getting crap for changing things from how they were in Windows 95. And I wish people would look outside of the confines of their chosen platform, and acknowledge the positive contributions that other companies are making. Get out of your bubbles!3 Other systems are great and interesting and useful, too!

This goes further than just interaction design. For example, I hope Apple keeps holding Google’s feet to the fire on the topic of privacy and encryption, and I hope Google’s more open stance on app development and on platform access will eventually force Apple to follow suit.4

The more competition, the better the products. The worst thing that could possible happen to each one of us would be for our favorite company to win, and for everybody else to stop competing.

(This was originally published as part of the window management article.)


  1. Regardless of what device you’re currently using, unless you actually own huge amounts of stock in one of these companies, or work for them, please remember that the manufacturer of the device or the OS you’re using doesn’t really care about you. There’s no need to feel emotionally attached to a legal entity; it can’t feel the same towards you. Obviously, we humans intuitively do this, we like one company over another, but I think it’s worth consciously reminding ourselves from time to time that this is a one-way street. back

  2. I’m only using Apple aficionados as the example in this sentence because I’m one of them, not because they’re particularly guilty of this. The situation on the Android and Microsoft (and Linux) sides is similar. It’s possible that we Apple customers are a bit more susceptible to «us vs. them» thinking due to Apple’s near-death experience in the 90s, but in general, the difference between the groups is small. back

  3. Case in point: how many of the people who loudly declare Windows 8’s attempt to merge desktop and tablet UIs a «terrible idea» have actually used a Surface for any amount of time? back

  4. As an aside, there’s this meme going around that apps are this generation’s new art form. I think this is true, but I also think it is a pretty sad statement on this generation that its new art form is one that is effectively controlled by a single multinational corporation that will not allow art that involves political caricatures, overt social criticism, or nudity. If paint and canvas had those same restrictions, the only paintings we’d have from the old masters would be still lifes of fruit bowls. back

If you require a short url to link to this article, please use http://ignco.de/709

Window Management and Apple

The lack of split screen view has always been one of my major complaints about iOS. With iOS 9, Apple is1 going to add a simple tiling window manager to iOS.

Dr. Drang writes:

Unlike Mac users, iPad users won’t be dumped immediately into a multitasking environment. Those who prefer to use and see only one app at a time can continue to do so—the multitasking interface will stay out of their way and won’t confuse them.

But for those who need to refer to one app while working in another, Slide Over and (especially) Split View will be a godsend. And it’s seemingly eliminated one of the biggest problems with using Mac-like multitasking environments: window management. There are no windows in Split View, there are only parts of the screen, with one part wholly given over to one app and another part wholly given over to another. There’s no overlap and there’s no Desktop peeking out from behind. The only thing the user has to think about is the position of the dividing line between the two apps.

Here’s a video of Craig Federighi, introducing the new feature.2

This is very similar to what Windows 8 does, but, in an odd way, seems to be less predictable, less powerful, and more complex. Notice how Federighi is on the home screen, jumps to the task switcher, opens Safari, and then swipes in from the right. This shows Messages, and Federighi acts as if that was exactly what he had expected to happen, but… why? Why is it Messages and not some other app? He just swiped in from the right, how does iOS decide which app to show?3 I would assume that, since there are dozens of apps you might want to see, and only one app that actually gets shown, the app you’re actually swiping in will be the wrong one most of the time.

You can pull down from the top and change the app, but now you’re doing some serious interface magic, where you have to know to swipe in from the right to show the app, then swipe down from the top to show the task switcher.4 There are no real affordances5 for either of the two actions.

Note that, so far, you’re not actually in split view. You’re still in «slide over» view. There are two different multitasking views in iOS 9 — another layer of complexity. To go into split view, you have to know about another piece of hidden interface magic: tap on the divider, and you turn on split view (unless you don’t have an iPad Air 2).

Federico Viticci notes that

Apple is also giving developers the ability to opt out from multitasking and they’re saying that camera apps and hardware-intensive games should probably eschew multitasking.

This seems to add additional inconsistency to an already odd implementation of the split window feature.

This reminds me of 90s Internet mystery meat navigation, except that there’s not even any mystery meat, and you’re just randomly dragging around and tapping on things to trigger actions that might or might not be supported by the application you’re actually trying to use. You could argue that split view is a power user feature,6 and power users can just go watch a YouTube movie that explains how the feature works, but I’ve now watched this section of the keynote twice, forgotten how it works once already, and I’m completely sure that I will have forgotten how it works again by tomorrow.

This is exactly the kind of magical user interface that people have faulted Windows 8 for, except it’s even more confusing. In Windows 8, you only had to remember to swipe in from the screen edges. Once you did that, the UI was visible, and guided your actions. In iOS 9, it’s layers of hidden UI magic. The one advantage Apple has is that you don’t need to know any of it to use iOS, but still. I think we should expect better of Apple.

Because the thing is: it is not necessary to have all of this complexity.

Windows 8 has a more powerful split view that is also hidden from novice users, but still manages to be easy to learn and intuitive to use. Drag in from the left to show the task switcher. Tap on a window to activate it. If you’re a power user, all you have to learn is that you can also drag windows from the task switcher. Now you can drag them into the screen and place them where you want them to be, either as new split views, or replacing windows already in split views.

No hidden secondary task switcher, no multiple split screen modes, no excluded apps.7

In conclusion, I’m extremely happy that Apple is introducing a split screen view on iOS, but it’s difficult to understand why they decided to go with such a complex user interface. It all looks nice, but the interaction design seems, well, odd, and a little bit concerning.

El Capitan

At the same time, Apple is also starting to tackle window management on OS X. Here, Apple is trying to figure out the same kind of balancing act between the existing window management system, and a new, simplified one, that Microsoft has failed to solve with Windows 8, and is trying to improve upon with Windows 10.

There seems to be a new kind of hierarchical window management system for full-screen apps, where «inner» windows can be minimized into tabs at the bottom of the screen (kind of like tabbed folders in Mac OS 9). There’s also a new split screen mode that shows windows side by side (and if you do that in the normal window manager, you seem to be put into the full-screen window manager automatically).

Putting all of this stuff on top of all of the existing window management cruft doesn’t exactly make the Mac’s window management system simple and easy to understand. I think Apple is trying to avoid Microsoft’s mistake of having two completely separated window management systems on its desktop OS, but it’s becoming clear that the alternative — one system that tries to accommodate vastly different kinds of usage — is no panacea, either.

Either way, iOS and Mac OS are taking another small step towards each other. Nobody can predict the future, of course, but it seems possible that, as iOS becomes more powerful, and Mac OS gains features from iOS, the two operating systems might eventually converge into two versions of the same product.

Natural Language

Apple also showed a nifty new natural language search. But if they have all of this data, and know when a user worked on a document, and with whom that user worked, I wish they’d just expose this data in a real graphical user interface. I’m never sure how to talk to natural language UIs, and if they fail, I’m never sure if it’s because the system doesn’t have the information to answer my question, or if I merely asked the wrong question. Just give me a visual UI for things like date- or people-based file management.

Progress

I’m not a fan of some of the UI decisions Apple has made, but I am a huge fan of the basic concept. I think that a lack of power in all areas is one of the reasons why iPad sales are shrinking. Unless your needs are very specific, and quite limited, the iPad is a poor choice of device for getting work done. With the split-screen view, Apple is starting to address one important aspect of this problem. Other aspects — lack of availability of professional apps,8 sharing files between apps, organizing documents by project instead of by app, and others — remain only partly solved, or entirely unsolved. There’s still a lot of work to be done to make the iPad a viable desktop PC replacement for most people, but Apple just checked off an important item on this list.

I’m very happy that Apple is making a step in this direction.

Update

This article originally contained a section on partisanship and competition. I’ve put that into its own article.


  1. Finallyback

  2. BTW, I hope they improve the «keyboard as a trackpad» feature before it ships, because in the demo, Federighi doesn’t seem to be able to easily select text without also typing gibberish at the same time. back

  3. Maybe it’s the last used app, but what if the last used app is not supported? What if you’re starting from the home screen? It must often seem non-deterministic to the user. Apparently, it’s the app last put into sidebar, which is logical, but mit not be entirely intuitive. Depends on how people will use the feature. back

  4. But you can’t swipe down to change the app on the left side of the screenback

  5. Apart from a small grey pill at the top of the «slide over» panel, that is presumably intended to tell you that you can swipe down to trigger some kind of action. All of this is exacerbated by the «flat» user interface, which lacks many of the ambient interaction hints that come from having user interfaces that are closer to what humans interact with in the real world. back

  6. Though it seems a bit strange to assume that regular users would never want to see, say, a website and a Pages document at the same time. back

  7. Though Windows 8 does have the «drag in to get a random app» feature, same as the iPad. Thankfully, you can turn it off. And you should. back

  8. Perhaps in part because people are unwilling to invest a lot of money into developing an iPad app if they can’t be sure it will be approved, which hurts sales of apps that are available, because you need an ecosystem of different apps for a platform to become viable. back

If you require a short url to link to this article, please use http://ignco.de/708

Web App Speed

When Apple originally released the iPhone SDK in 2008, I was extremely excited about it, and immediately started working on multiple different iPhone apps. By 2009, though, I had become so uncomfortable with Apple’s stewardship of its mobile platform that I released the one game that was furthest along, and abandoned the other games and apps. In hindsight, that probably was a good idea, because at least one of the apps I was working on (temporarily) became illegal, according to Apple’s App Store guidelines.

Instead, I started looking into writing web-based games running in Safari. As part of evaluating whether it was technically possible, whether the original iPad could even run web-based games acceptably well, I wrote a simple two player tower defense game.1 Here’s the game, running on an original iPad.

I spent very little time optimizing this code, and there’s probably plenty of room to squeeze more performance out of it. Even so, the game easily runs dozens2 of independently moving sprites, has pathfinding, and displays a progress bar on every single tower, resulting in hundreds of simultaneously, independently moving pieces — all on the original iPad.

Since then, web performance has skyrocketed. If I run sunspider on my original iPad, it totals 2761 ms. According to Macworld, the iPad Air 2 runs it in 287 ms.

You can see the game for yourself here (it only runs on iPads, because I’m detecting if it’s installed on the home screen, and because I’ve hard-coded the screen size).

Getting this tower defense game to run properly on an original iPad was easer than getting the native game I released to run properly on an original iPhone. It took me two days to write the whole tower defense game, including doing some simple optimizations. It took me months to write the iPhone game, including porting it from Apple’s native APIs to OpenGL, and spending a lot of time in Apple’s profiling tools, trying to fix performance and memory problems.

To be fair, the first iPhone was quite a bit slower than the first iPad, and very memory constrained. But still, I think this is something to keep in mind when people complain about web app performance. If you don’t think that native apps were impossible to get to perform properly one or two device generations ago, then neither should web apps be impossible to get to perform properly on today’s devices.

Having said that, the people complaining about poor web app performance do have a point. Most web apps do perform poorly. I just think that blaming browsers, and concluding that web apps can’t perform well, is misdiagnosing the problem.

Why are many web apps performing so poorly?

DOM manipulations can be slow, and are difficult to optimize

One of the reasons why my tower defense game performed quite well despite not being highly optimized is that it avoids using the DOM for most of its UI. Instead, it uses the HTML canvas3 to draw pixels directly.

Importantly, though, that’s not to say that DOM-based web apps can’t be fast. In fact, I’ve written complex DOM-based web apps that achieved native-like performance (and a native-like interaction design) way back when the target platform was IE6. However, optimizing performance on these apps can be hard, because DOM manipulation can be slow if done carelessly, and browsers sometimes behave slightly differently in ways that aren’t immediately noticeable to the developer, but result in vastly different performance across different platforms when doing the same DOM manipulations.

In short, it’s absolutely possible to write web apps that use the DOM and still perform well, but, particularly for more complex user interfaces, it does require developers to spend time optimizing their code.

And, of course, you don’t have to use the DOM if something else works better for your particular app.

As an aside, this is often where people sneer and say something like «well, it’s not a real web app if it doesn’t even use the DOM», but that seems weird to me. That’s like saying «it’s not a real native app if it uses OpenGL». Drawing some — or all — of a native app’s UI without using Apple’s own frameworks is not «a scathing condemnation» of UIKit. In fact, my own native game uses OpenGL for almost everything it draws, just like the web-based game uses canvas for almost everything it draws. And just like the web-based game uses the DOM to draw stuff like buttons and the help screen, so does my native app use Apple’s UI frameworks for this aspect of the game.

Nothing about using the canvas makes a web app any less «webby.»4 All of the good things web apps bring — cross-platform compatibility, simple deployment, a high-level language, an open platform — are available to you whether or not you’re using the DOM for most of your UI. The DOM works well for some things, and canvas works well for others — that’s why there is a canvas. Pick whichever works for you.

It’s hard to find good JavaScript developers

JavaScript has a bad reputation among developers. Part of it is deserved,5 but much of it probably stems from the fact that it was originally used to make annoying DHTML effects like sparkling mouse cursors, and from the fact that it is not a traditional class-based programming language, and thus seems weird and confusing to many new JS developers. It’s pretty easy to pick up the basics of C# if you know Java or Objective-C, for example, but learning JavaScript requires a larger shift in how you think about and structure your code.

I suspect that this is why many developers never bother to learn JavaScript.6 As a result, there are very few good JavaScript developers out there.7 At the same time, demand for JS developers is rising fast. Since somebody has to write all of that JS code, it’s sometimes written by people who might not be entirely qualified for the job.

People use a lot of needless middleware frameworks

This is related to the previous point. People don’t want to learn JavaScript. They want to keep writing code in a way that’s familiar to them. So people build vast layers of indirection that hides how JavaScript actually works.

Back when I wrote web apps that targeted IE6, I evaluated a ton of JS frameworks. I ended up not using any of them, because all of them caused huge performance problems. This is exactly where we are today with mobile web apps. Performance of a 2005-era PC running IE6 is roughly about what you’ll get out of a 2015-era mobile phone running a current version of Chrome or Safari. It was possible to create a fluid, responsive PC web app in 2005, and it’s possible to create a fluid, responsive mobile web app now, but not if you rely on megabytes of (sometimes poorly written) JS frameworks that all have to be downloaded, parsed, and executed by a mobile browser, killing loading time, execution speed, and bloating memory usage.8

Peter-Paul Koch wrote:9

Tools don’t solve problems any more, they have become the problem. There’s just too many of them and they all include an incredible amount of features that you don’t use on your site — but that users are still required to download and execute.

If at all, web devs optimize for loading speed, not execution speed

When pages were mostly static and people were using slow analog modems to dial up into the information superhighway, loading speed was all that mattered. That’s why we have a ton of good profilers to improve loading speed, and different techniques for caching and compressing data. Loading speed briefly became very relevant again when mobile phones started connecting to the Internet, and initially suffered from very slow connection speeds. To some degree, that is still the case, and people should optimize for it.

Most web developers probably don’t optimize for loading, but even fewer optimize for execution speed. With today’s fast connections and dynamic websites. execution speed often becomes a bigger issue than loading.

Admittedly, optimizing load times is easier than optimizing execution speed, since we have more experience doing it, and the profiling tools for loading optimization are more sophisticated. But it is becoming increasingly important to look at execution speed, as well.

Ads

And finally, the thing that kills mobile performance: loading dynamic, animated, interactive overlay ads from crappy, slow third-party ad servers. How often do you open a page on your mobile browser, and it’s painfully obvious that the thing you actually want to see — an article, for example — has already loaded, but is hidden below layers and layers of shitty ads that are slowly pulling in stuff, preventing you from accessing the thing you actually want to see?

You can’t have a fast web app if you’re monetizing it by punishing your users with shitty ads.

Conclusion

It’s frustrating to see people complain about bad web performance. They’re often right in practice, of course, but what’s annoying is that it is a completely unforced error. There’s no reason why web apps have to be slow. The technology to make fast web apps is here — we just have to take advantage of it.

Addendum

Discussion on Hacker News.


  1. I never continued work on it, because I eventually became so uncomfortable with Apple’s behavior (and Android got to a point where it was a valid alternative to iOS, and arguably even superior in some ways) that I pretty much stopped using iOS devices altogether. back

  2. I’m not sure where exactly it starts to slow down, but I’ve seen 70 or 80 sprites without apparent slowdown. back

  3. Related: Flipboard blog post about how they use canvas, and avoid the DOMback

  4. And you can make canvas-based apps accessible. back

  5. Though it’s easy to just not use most of the bad parts in JavaScript. «Doctor, it hurts when I do this.» — «Well, just don’t do that, then.» What remains if you avoid using the bad parts is a programming language that’s extremely flexible, and extremely pleasant to use — if you take the time to actually learn to use it. In fact, going back to writing Objective-C or Java code after becoming comfortable with JavaScript is probably harder than learning JavaScript in the first place :-) back

  6. And why most CS curricula don’t include classes on optimizing JavaScript code. back

  7. If you are one of the select few good JS devs, please apply here :-) back

  8. Tammy Everts: «It would take 17 circa-1984 Macs to store one modern web page.» back

  9. Via Marco Armentback

If you require a short url to link to this article, please use http://ignco.de/703

Yotaphone 2

I really like e-ink displays. I’m not a huge fan of OLED displays, though; they’ve become much better in recent years, but they can still be difficult to read in bright sunlight. Conceptually, the Yotaphone 2 made a ton of sense to me. I’ve been using one for a month now.

The hardware itself is beautifully designed. It looks fantastic. Because there’s no home button, and because the SIM card slot is hidden behind the volume buttons, the device itself seems almost featureless.

It’s very thin, particularly considering that there are two screens in that thing. The phone’s edges are bent inwards, which looks amazing, and makes it easier to hold.

The back screen is slightly curved along the left and right edges, which is cool and makes it easier to hold, but can be annoying when you actually use the screen. The back screen has an antireflective coating, which also gives it a bit of grip. It’s still a pretty slippery phone, though.

All in all, I think this is one of the most beautiful phones on the market right now.

Battery Life

The phone has a 2500 mAh battery, which is kind of anemic by today’s standards. The phone I carried previously, a Galaxy Note 3,1 released back in 2013, came with a 3,200 mAh battery. As a result, battery life is not great. I usually get around 14 hours of life out of the device, which means that the phone typically doesn’t quite make it through a day. It’s about on par with what I got out of the iPhone 4S I used to own,2 and quite a bit worse than the Note 3.

Ostensibly, the e-ink screen is supposed to fix this problem; just avoid using the OLED screen, and battery life will skyrocket! Reviews of the phone claim that you can easily extend the phone’s battery life from one day to two or even three. To me, this doesn’t seem plausible. On average, my Yotaphone claims that the OLED screen is responsible for about 25% of its battery usage. If I only used the e-ink screen,3 that would extend battery life from 14 hours to maybe 20 hours — nowhere near two days.

The battery problem is compounded by Android’s terrible standby battery usage. iOS barely uses any battery if the device is in standby mode. I can let an iPad sit on my desk for a week, and it’ll still have a charge when I turn it back on. The same can’t be said for Android. Unless I turn my Android devices off, they keep draining battery at a pretty astonishing pace.

All of this means that even if I avoid using the OLED screen whenever possible,4 the Yotaphone still has pretty mediocre battery life. That doesn’t mean that the e-ink screen is irrelevant to battery life, though. Having it means that I can read a book on my phone without draining the battery in a few short hours.

In other words, the e-ink screen doesn’t allow me to easily make it through more than a day on a single charge, but if I do something on my phone that requires me to look at its screen for long periods of time, it will prevent the battery from dying prematurely.

Hardware

The phone doesn’t have a replaceable battery or an SD card slot. I don’t mind the battery part that much, though I would prefer to be able to swap the battery. The missing SD card slot, though, is a bigger problem. The Note 3 I used previously had 32 GB of internal storage, and I added a 128 GB SD card. The internal storage held apps, the external storage held downloaded podcasts, photographs and movies taken with the phone, and similar data. As a result of this, I effectively did not have to care about storage space. Going from not having to even think about storage space to having to actively manage storage space sucks, and just shouldn’t be necessary anymore.

The phone’s front screen is covered with Gorilla glass 3, but for some reason, I’ve already noticed some faint scratches. They’re barely visible, but still; this is something I haven’t seen on a phone in a long time. It’s a 5 inch AMOLED screen with 1920 × 1080 pixels, which is more than good enough, even though it seems comically small after using 6 inch screens for years.

The back screen is also covered by Gorilla glass 3; at 4.7 inches, it has 960 × 540 pixels, a resolution of 235 ppi. I’d like it to be slightly higher, but it’s certainly good enough for most situations. The back screen is curved at the edges, which looks really cool (and makes the phone easier to hold).

Unfortunately, it can mean that it’s harder to find a position where there’s no glare on the back screen — a problem that Yota’s own picture of the phone shows beautifully.

The back screen’s texture makes it less reflective and helps make it less slippery, but when holding it «backwards», you’re effectively holding a slab of glass. This is particularly problematic when you put it down backwards on a table or sofa. If it’s not entirely flat, the phone will just slide away.

One issue I’ve noticed with the e-ink screen is that the Yotaphone is not great at detecting when it should do a full refresh. E-ink screens show a visible ghost of the previous image. To get around that, e-ink devices refresh the screen from time to time (turning the full screen white, then black, then white, resulting in a visible flash). Yotaphone’s built-in apps that are specifically designed for the e-ink screen know when to do that, but if you use normal Android apps on the e-ink screen, the phone seems to have some basic heuristics for deciding when to refresh the screen. Sometimes, this works well, but other times — when using the Kindle app, for example — the refresh is barely ever triggered, and ghosting starts to accumulate.

The only thing that should be visible on this screen is the book page’s text, and a page number and progress percentage at the bottom. Everything else is ghosting.

It’s not a huge problem, just a small detail that could likely be improved with a software update.

The device has 2 GB of RAM, which is not quite enough to run Android well. The Note’s 3 GB of RAM meant that I could easily run multiple apps and switch between them, but on the Yotaphone, I can barely switch between two apps without the first one being auto-killed.

The camera on the phone produces quite beautiful pictures, even in most low-light situations. It’s not quite fast enough — from lock screen to taking the first picture can take a few seconds, and there’s perceivable shutter lag. The camera sometimes has problems auto-focusing on objects close to the lens, but tapping on the screen to manually focus, and then taking a picture, usually fixes the problem.

Like the iPhone, the phone doesn’t have an LED. Personally, I really like notifications LEDs, since I tend to leave my phone lying around, and the blinking light tells me if I’ve missed any notifications. No such luck on the Yotaphone, though.

Integration

The Yotaphone 2 runs stock Android with some added features related to the e-ink screen. There are basically four different ways you can use the e-ink screen:

  • YotaPanel puts interactive widgets on the e-ink screen (alternatively, you can put a picture on there, but, weirdly, you can’t have a picture and some widgets)
  • You can take a screenshot of the front screen, and put it on the e-ink screen
  • Special e-ink apps can be launched from Android, and then take over control of the e-ink screen
  • YotaMirror allows you to use regular Android apps on the e-ink screen

Of the four, YotaPanel and YotaMirror are the most useful. The e-ink apps are cool, but there are only a few of them. Putting a screenshot on the back panel sounds useful (you might think that could take a screenshot of a train schedule, for example, and always have it available on your phone — even if it runs out of power), until you realize that the screenshot only stays on the back screen for a few mintues, until the phone decides to go back to showing your YotaPanel widgets. And once the phone starts running out of juice, it automatically puts an «I’m in battery saving mode» picture on the back screen.

YotaPanel and YotaMirror are really cool. Just being able to see the time without turning on the phone is actually more useful than I thought. I can’t help but think that there’s more you could do with a touchscreen on the back of the phone, though. How about using the back touchscreen to send touch events to the front touchscreen, for example? That would allow you to play games without covering the touchscreen with your fingers.

One interesting aspect of the Yotaphone is how the phone figures out which screen you’re using. Through experimentation, I’ve come to the conclusion that it uses both the phone’s orientation and its touchscreens to decide which screen you’re looking at. If your hand covers one of the screens, it assumes that you’re looking at the other screen. If it can’t tell based on that, it assumes that the screen pointing up is the one you’re looking at. In everyday usage, this works surprisingly well; at times, it’s almost spooky how well the phone knows what I’m doing. Lock the phone, turn it arouhnd, unlock it — now the other screen is unlocked. It’s not quite perfect, though. Every few days, I’m looking at the OLED screen, and it suddenly goes dark — because the phone somehow interpreted my hand movements as an attempt to unlock the back screen.

Android

Yotaphone’s e-ink screen has caused me to neglect my Kindle a bit, and do more reading on my phone. This has given me a renewed respect for Android, and really reminded me of why I switched from iOS to Android. Just the Kindle app alone is so much better on Android than iOS. It can use the volume buttons for turning pages, which works beautifully on the Yotaphone. And it has a built-in, fully integrated store!

But using it has also reminded me of the issues I have with Android, particularly with its hardware ecosystem. There are a ton of different Android phones, but they’re all variations on the same theme. The few phones that do something special typically only do one thing. You can get the waterproof phone, or the phone with the pressure-sensitive pen, or the phone with the superhuge screen, or the phone with the e-ink screen, or the phone with the multi-day battery life, or the phone that’s rugged and won’t break if it falls, or the phone that has a fantastic, fast camera, or the phone that has two SIM card slots, or the phone that has a lot of internal storage — but you can’t get a phone that does all — or even more than one or two — of these things.

My phone is probably my most used electronic device I own. I want to do sketches on my phone, but for that, I need a pressure-sensitive pen and a larger screen. I want to take my phone everywhere I go, but for that, it should be waterproof and rugged. I want to read books on my phone, and use it in bright sunlight, and for that, an e-ink screen is a fantastic feature. And so on.

The phone I want doesn’t exist.

Conclusion

The Yotaphone 2 is an incredibly beautiful phone with one incredibly useful feature. I just love going for a walk in the sun, turning on the OLED screen, seeing almost nothing, turning the phone, and being able to see its screen perfectly. I particularly love reading on this thing.

But this is also a phone that has quite a few flaws, and that I can’t easily recommend to most people. Unless you do a lot of things that work well on the e-ink screen, this phone is probably not for you.

For me, I love e-ink screens so much that I will put up with the phone’s problems, at least for now. In the long run, though, I wish that Android phone manufacturers would stop making «one special feature» phones, and instead start making more well-rounded phones that are aren’t kind of mediocre in every aspect except one.


  1. By the way, comparing the Note 3 to the iPhone 6 plus makes the 6 plus look a bit ridiculous. It’s quite a bit larger than the Note 3, but its screen is visibly smaller; side-by-side, the 6 plus looks bulky, and its design seems wasteful. back

  2. And carry in a Mophie Juice Pack. back

  3. And assuming that the e-ink screen uses zero battery. back

  4. Technically, you could use the device without ever turning on the OLED screen. All you need to do is add the Android launcher as one of the apps that can be launched from the back screen, then unlock the back screen and start the Android launcher — voilà, you’re running Android on your back screen without ever turning on the OLED screen! In reality, some apps don’t work well on the back screen, because they require colors or a higher resolution than the e-ink screen provides to be properly usable. back

If you require a short url to link to this article, please use http://ignco.de/699

Burger

BBC Magazine:

«I did multiple tests,» says James Foster, a web developer based in New Zealand, who has surveyed users’ interactions with the button over the course of many months. «The results all came out the same - the icon is not as clear to some users as developers and designers think it is.»

Adding the word «menu» underneath the three lines increases the button’s use by 7.2%, according to Foster’s tests.

Putting the hamburger inside a box, so it looks like a button, increases use by 22.4%.

Switching the lines for the word «menu» makes 20% more people click, Foster found.

(…)

People are getting used to the hamburger button - albeit slowly. Foster carried out his first test on users in early 2014, and has been testing since. Users do seem to understand it more.

The inventor of the hamburger - or air vent - is sanguine about his legacy. «Though I don’t condemn or condone its usage today, my guess is it’s probably here to stay,» says Norm Cox. «All the ‘controversial’ discussion about it has burned it even more into our digital vernacular.»

Recognition of the hamburger icon also depends on where it is positioned. If it’s positioned in an unusual location, putting a box around it is definitely a good idea.

At this point, replacing it with something else doesn’t seem to make sense anymore. Even Microsoft is putting it into its products now.

I guess we’ll just have to keep our heads down, push through the valley of incognizance that always occurs when we replace something people know with something they don’t, deal with the burger icon as well as possible,1 and hope that people will soon get used to it.


  1. This includes rethinking where it is located, particularly on mobile phones. iOS’s «navigation at the top» scheme made sense on a 3.5 inch screen; the larger the screen, the more problematic this approach becomes. back

If you require a short url to link to this article, please use http://ignco.de/700

My friend Jon Bell is now publishing things on Patreon. The first issue is online. Among other things, it contains two essays I’ve written, and one written by my friend Valentin Filippov.

Card Sort Generator

I was preparing for a card sort yesterday, clicking around in OmniGraffle, trying to come up with a good grid for the cards, entering labels, when it occurred to me that there had to be an easier way. A cursory Internet search didn’t reveal anything, so I made the obvious choice, and spent half a day implementing a tool that renders a card sheet PDF from a list of terms:

cardsort.ignorethecode.net

It’s pretty simple. Enter your list of terms, select US Letter or A4, select how many cards there should be on a page, and download the rendered PDF.

If you require a short url to link to this article, please use http://ignco.de/694

Matt Gemmell has written an extensive article explaining Windows Phone’s user interface from the point of view of an iPhone users:

This isn’t a review, or even a comparison. You can think of it as a sort of traveller’s guide for iPhone users, who find themselves in the land of Windows Phone. It’s also about the platform itself, rather than any specific handset.

Well worth reading.

Nintendo's Mobile Games

Nintendo is collaborating with/licensing its IP to DeNA, a mobile game developer. Some people are reading this as «Nintendo games on iPhones», but I think that’s making some tenuous assumptions. These are Nintendo games in the same way that this is the Apple watch:

Apple-branded quartz watch1

There’s a huge difference between «a watch with an Apple logo», and «the Apple watch».

All of DeNA’s currently available games are free to play. This isn’t entirely new territory for Nintendo, who has been flirting with free to play gaming for a while now. So far, they’ve released a bunch of free-to-play games on the 3DS, including the terrible Pokémon Shuffle2 — which, like these new games, was developed by a third party developer.

Pokémon Shuffle is not the first time Nintendo has licensed its IP to other developers, either. If you don’t remember the Zelda and Mario games for the Philips CDi, please try to keep it that way, because they were horrid.3

That’s not to say that Nintendo’s IP licensing always fails; Capcom made some truly fantastic Zelda games, and Sega’s F-Zero4 was one of the best games on the Gamecube.

Still, if you were one of the people asking for Nintendo to bring their games to iOS back in 2013, this is very likely not what you had in mind. John Gruber writes:

Not sure what to make of this yet, but it sounds like they’re doing what I suggested back in 2013.

Maybe I misread the essays back then, but my impression was that people were hoping that Nintendo would go the Square-Enix route, and release higher-priced premium games on iOS, not that they would license their IP to a third-party and allow them to make Mario-themed free-to-play Skinner boxes.5

In fact, Nintendo explicitly acknowledges that they won’t bring what most people think of as «Nintendo games» to mobile platforms:

We have no intention at all to port existing game titles for dedicated game platforms to smart devices because if we cannot provide our consumers with the best possible play experiences, it would just ruin the value of Nintendo’s IP.

It’s not clear to me what exactly Nintendo’s strategy is. They do point out that their console games sell well:

Last year, an unprecedented thing in the history of the Japanese video game market happened: Five titles for Nintendo 3DS sold more than two million copies each in the latter six-month period of 2014. As this record-breaking incident attests, video game software sales have been progressing smoothly on dedicated video game hardware even after smart devices have become widespread in this country.

Of course, the challenge of asking our consumers to purchase dedicated video game hardware has become harder now that smart devices have widely spread. However, we recognize that our business model of producing both video game hardware and software is effective even today, and we do not share this pessimistic view of the future for dedicated video game systems.

And Iwata acknowledges that Nintendo’s IP is its biggest asset:

When we further analyze the situation, Nintendo’s strength lies in, or our consumers see the most value in and are willing to pay money for, Nintendo IP, such as our software and characters, and we have been creating and nurturing them together with the history of home video game entertainment.

I don’t see how licensing Mario for usage in free-to-play games will «nurture» that character. Iwata suggests that the idea is to use these mobile games as «advertisements» for the real games:

Nintendo has made this decision because we have concluded that the approach of making use of smart devices is a rational way for us to encourage even more people around the world to recognize the great value of the wonderful game software available on our dedicated game systems.

(…)

We aim to construct a bridge between smart devices and dedicated video game hardware that connects consumers to our dedicated video game systems.

For the consumers who are connected with Nintendo through smart devices and interested in Nintendo’s IP, we would like to provide even more premium gameplay experiences on Nintendo’s dedicated game platforms. By taking this approach, we firmly believe that doing business on smart devices will not shrink our dedicated video game system business and will instead create new demand as this broader reach will enable us to provide consumers around the world with more opportunities to experience the appeal of Nintendo IP, and instead of trying to seize the other’s demand, dedicated video game systems and smart devices will benefit from the synergies created between them.

But I’m not sure that free-to-play games can work as ads for console games. You know, the ones where the developer’s incentive is to create a good game and get people to buy it, not the ones where the developer’s incentive is to trick people into constantly coming back to something that’s actually not very enjoyable. I’m buying Nintendo consoles exactly because I want to avoid these kinds of games.

I have no doubt that Nintendo will make a lot of money from this, at least in the short run. I’m just not convinced that this isn’t going to do more damage than good in the long run. Nintendo’s place in the market should be as an alternative to the terrible free to play games, not as yet another purveyor of them. That’s their value; if you buy a Nintendo game, you know it’s going to be good.

DeNA has published some good6 games, so there’s at least a chance that these will not be too terrible, particularly if Nintendo is involved in the development process. Still, this could easily end up being a case of «be careful what you wish for».

In the end, though, I’m pretty sure the next real Zelda game is still going to come out on Wii U, and not on the iPhone.

Addendum

Nintendo is now saying that at least some games might not be free to play:

Considering the issue further, Iwata said he doesn’t want to «choose payment methods that may hurt Nintendo’s brand image or our IP,» and that it is important to have a business model «parents feel comfortable letting their children play with. Also, it’s even more important for us to consider how we can get as many people around the world as possible to play Nintendo smart device apps, rather than to consider which payment system will earn the most money.»

Also relevant:

Elsewhere in the interview, Iwata clarified that the actual development of games as part of the mobile partnership will «be mainly done by Nintendo,» though legendary game designer Shigeru Miyamoto will place priority on continued development of Wii U titles. Iwata also reiterated that Nintendo wouldn’t just port existing console games to the mobile marketplace wholesale, owing to differences in the platforms. «My understanding is that, on smart devices, the main demand is for very accessible games which smart device users can easily start and easily finish,» he said. «These are not necessarily the characteristics that people demand from games for dedicated video game systems.»

Sounds promising. I guess we’ll see.


  1. Image sourceback

  2. The Verge: «Nintendo has started making bad free-to-play games like everybody else - Pokemon Shuffle brings the worst of mobile gaming to your 3DS.» back

  3. Remember when Sega still made good games? Getting out of the hardware business sure did wonders for them. back

  4. Hence my argument that Nintendo could make more money selling 60$ games with an attach rate of 50% on the Wii U, than premium-priced games on the iPhone. back

  5. Good for a free to play game, that is. back

If you require a short url to link to this article, please use http://ignco.de/693