Menu

Tag Archives: ui

In 1940, Ub Iwerks, the animator behind Walt Disney’s first Mickey Mouse shorts, came back to the Disney studios after a 10-year absence. Ub had famously produced hundreds of drawings alone each day for one of those first Mickey Mouse shorts, but Ub’s return to Disney would also be remembered for his contribution to the technical side of film production, with advances in cameras and special effects. In an industry with extreme specialization — you either did backgrounds, or animation, or ink-and-paint — Ub’s talents bridged both the artistic and technical.

One of Ub’s inventions while away from Disney was called the multiplane camera. Perfected by others leading up to Snow White, in a massive camera stand over 10 feet tall, the multiplane’s innovation was to allow a background to be split into levels. Foreground trees might be painted on the glass of the first level, then the characters sat underneath that, and then farther back layers for a building, with others behind that for hills and sky.

To provide a sense of depth, camera operators could vary the distance between each plane. And movement for each level could be synchronized at different speeds, giving it a beautiful parallax effect. Distant background levels moved more slowly and were naturally blurred and out of focus.

80 years after Ub’s invention, the multiplane is alive in iOS 7. Previous versions of iOS were built on a single plane with raised and textured areas on that surface, like a topographical map except with buttons instead of mountains. iOS 7 is instead designed with multiple flat layers. Each level is strikingly flat, but by layering two or three, spaced apart, Apple has achieved an overall sense of depth.

It’s a return to basics. Simple things can remain simple, readable. When clarity is needed, everything goes flat. But it’s a framework that allows for subtle motion and depth without changing what works about the new, content-first flat design. iOS 7’s control center blurs the layer below. The home screen background sits deeper too, as if only the app icons are touching the screen. Photos scroll under the navigation bar.

Each plane is painted flat as if on glass. There can be no text drop shadows, no textures, without ruining the effect. And the result of this strict metaphor is equally valuable: there are no drop shadows to distract or obscure an app’s real content.

Disney’s multiplane camera, first in a dedicated rig and then recreated in software, lasted for decades, until the era of 3D computer animation. iOS 7’s new look won’t last that long, but the core concepts should carry Apple for years. I really like where they’re headed.

Clipstart 1.0 tried to be smart about not importing videos that were already in your library, but it stopped short of actually giving you much control over whether to import duplicates or ignore them. I also felt like the window showing duplicates could be improved to provide more information about each file. At a glance you should be able to tell if Clipstart is doing the right thing.

So I put a lot of effort into this for the soon-to-be-released Clipstart 1.2.4, and the result is this window:

It generates a few frames of the timeline for each video (both old and new file side by side), which turns out to be an excellent way to confirm that they are indeed the same file, and also shows the original filename even after Clipstart (or the user) has renamed it. Now I can scan through the window in about 2 seconds and I’m done. Contrast with iPhoto which prompts after each video is imported, instead of at the end of the batch, and if you blindly trust it by checking “Apply to all duplicates” then you have no feedback on whether you made the right choice.

The new duplicates window works with both volume-based cameras like the Flip and SD cards, as well as USB devices such as the iPhone 3GS and iPod Nano. I hope to ship version 1.2.4 soon, and there’s a “beta in the forums”:http://www.riverfold.com/forums/topic.php?id=49.

Update: As pointed out by a customer, Ignore and Keep are actually pretty confusing verbs here. I’ve changed it to “Skip Duplicates” and “Import Duplicates” for the final release.

“Gmail also showed how much you could do with web-based software, if you took advantage of what later came to be called ‘Ajax.’ And that was the second cause of Microsoft’s death: everyone can see the desktop is over. It now seems inevitable that applications will live on the web — not just email, but everything, right up to Photoshop. Even Microsoft sees that now.”

He’s definitely off the mark with that statement. Luckily “Martin Pilkington has a counter-rant”:http://pilky.mcubedsw.com/index.php?/site/the_desktop_is_here_to_stay/:

“There seems to be a slightly delusional section of web developers who seem to believe that in a few years time all of our applications and data will be online, while our computers run little more than a browser. Of course this is complete bull.”

As someone who builds both desktop software and web apps, I’m very much interested in what happens in the middle. Next generation Mac software in particular can mix local HTML interfaces, web services, and syncing with a traditional rich UI to build something that is the best of both offline and online worlds.

I had an interesting conversation with “Willie Abrams”:http://willie.tumblr.com/ the other day about why the Flickr UI is better than iPhoto, even if you take away all the social parts of Flickr. The reason is that Flickr introduces extra layouts specific to certain types of activities, such as the excellent calendar view for archives. Another example of a web app UI innovation is the Backpack reminder UI that “John Gruber recently wrote about”:http://daringfireball.net/2007/03/deal_with_it.

Web apps are usually able to iterate on features and interfaces much quicker than desktop software, but that doesn’t make web apps inherently better. Put another way, iCal sucks because it hasn’t been seriously updated in 5 years.

I have other thoughts on this topic, but already I’ve extended this blog post 3 paragraphs more than intended.

“Last week I said”:http://www.manton.org/2007/01/macworld_2007_predictions.html I wasn’t interested in an iPod phone, unless it was something no one had even thought to expect. Well, it is. I am blown away by the iPhone. The thing runs Mac OS X.

The iPhone is really inspirational in terms of UI design polish. You can tell they put some years into it. I was playing with Tiger’s NSAnimation the other night (sort of a poor man’s “Core Animation”:http://www.apple.com/macosx/leopard/coreanimation.html), and it reinforced for me the fact that UI effects are no longer optional pieces of software design. They can both visually supplement the user interaction and just make the application experience more enjoyable. “Disco”:http://www.discoapp.com/, for all the criticism as a glorified Disk Recording framework wrapper, is fun to use. Same goes for the just-released “Snapshot 2.0”:http://www.stuntsoftware.com/Snapshot/, which has a really thoughtful single-window UI.

This is going to be another great year to be a Mac developer. And we haven’t even seen the rest of Leopard yet. Only bump in the road will be if iPhone is a closed platform. The “comments over at Theocacao”:http://theocacao.com/document.page/404 provide some interesting commentary on that question.

Today marks the 4-year anniversary of this weblog. What better way to celebrate than with a discussion of web applications.

Willie Abrams said in a recent Campfire chat: “Web applications automatically have sync.” He hits on the fundamental principle of web applications popularity, and of course that has always been true. But the difference now is that some web apps are actually fast and usable too. (Gasp!)

The rise of rich web applications that seamlessly mix Flash or Ajax while still staying true to the roots of web architecture (REST design, open standards) has upset the traditional desktop market. I first wrote about this in “To-do lists and embracing the network”, which was in a sense a subtle wake-up call to Mac developers: adapt to the always-on internet or any college drop-out with a shared server will obsolete your app after a few late nights of Rails hacking.

But it frustrates me to see such praise given to web applications that, were they traditional, native apps, they’d be laughed away to obscurity or ignored. Ajax is a huge advancement, but that doesn’t mean that every application works well for the web. I’m sure Google engineers spent an incredible amount of work on Google Pages, but compare it to Apple’s iWeb and it becomes obvious how weak web application interfaces still are.

Luckily some people are working through the really tough problems. Ray Ozzie’s Live Clipboard may be the start of a whole new shift in web app functionality, allowing data to move between web sites and even out of the browser. But true drag-and-drop of structured data between a native app and a web site is still a long way off.

Let’s make some lists, starting with the good.

Good web applications are data-driven, multiuser, and use URLs everywhere.

There is some key component that is about the browsing experience. That might be sifting through large amounts of data, viewing old logs, finding people.

The kind of data requires an adaptable user interface, not something with a strict set of traditional widgets. HTML is perfect for this.

On the other side are web applications that might be built by a team of smart people and with a great technology backend, but the application concepts are confused. They don’t know if they belong in a web browser or on the desktop.

Mediocre web applications think that a single web browser window is an entire windowing system with movable child windows.

No features that actually have anything to do with the web. The result is that it adds no value to the web as a whole.

Trying to replace the whole Microsoft Office suite.

Something else is changing in the HTML/CSS/JavaScript platform. In 2004, Joel Spolsky wrote about how instead of picking Mac, Windows, or Linux APIs, developers are building for the web platform and can deploy to any user’s desktop. Cutting-edge web applications push that claim to its breaking point, as differences between Safari, Mozilla, and Internet Explorer often cause headaches for developers. It’s no surprise when Microsoft’s set of Office Live applications require Internet Explorer, but it is note-worthy when Google’s chat interface does not work in Safari. There is now a whole set of web applications that require the latest version of Mozilla and won’t work in anything less.

Five years ago we accepted that web applications were going to be useful but ultimately unfulfilling, joyless experiences. Now most web apps have risen from bad to simply mediocre. The truly great ones have a foundation and design that would still be unrivaled in a desktop app. These amazing apps are not content to reimplement an old application as a web app just to allow use from any machine, but they take it to the next step: rethink the problem, stay agile, and redesign so that it’s not just web-based, but it’s actually better.

Everyone complains about software bloat. And it’s easy to see why — applications are bigger and slower than they’ve ever been, and users think the dozen features they will never use are to blame.

On the Mac we are lucky to have a large number of great, small, focused tools that solve a few problems well. The best of these become successful, but what then? You have to keep adding features. How do you control the software so that it becomes even more useful without feeling too packed?

One way is to differenciate between visible and hidden bloat. For example, Microsoft products used to have a tendency to take every major bullet point on the side of the box and make a toolbar icon for it. Even if the user only uses 5% of those features, they have easy access to far too many of them, and they needlessly have access to them all at once.

Instead, adding features in context allows the application to grow without feeling too busy, and without distracting the user from the core set of features they are familiar with. The new user interface is discovered by using a new feature, and otherwise remains out of sight.

This point was really emphasized for me while using Keynote 3 the other day. I love the contextual floating slider when editing a shape (see image). They could have put this slider in the inspector window, but it is so infrequently used it would have remained disabled most of the time, and cluttered those panes with little benefit.