Fuse Condos Interactive Touchscreen. Modern condominiums deliver an interactive display of the entire location for users to browse. 

Interactive Touchscreen Ordering Menu. Qwick Media. Fully customizable interface for ordering food at a location.

FF Chartwell is a fantastic typeface for creating simple graphs. Using OpenType ligatures, strings of numbers are automatically transformed into charts. The visualized data remains editable, allowing for hassle-free updates and styling. 

LOS ANGELES NIGHTFALL
Photographer Colin Rich gives a time lapse tour of light through the City of Angels.

Under the hood: Rebuilding Facebook for iOS

Article: Source

Today we released a new version of Facebook for iOS that’s faster, more reliable, and easier to use than ever before. The development of this new app signals a shift in how Facebook is building mobile products, with a focus on digging deep into individual platforms. To understand how we approached this shift, let’s take a look at how Facebook has evolved on mobile.

Three20

Early versions of Facebook for iPhone were built when iOS was in its infancy. There was no iPad and iOS wasn’t even called iOS. Out of those early versions of the app, we built an open source framework called Three20: a library of handy components that didn’t exist in iPhone OS at the time. Over the years Three20 became one of the most popular open source projects for the iOS community and solved many problems for us, but it also started to feel long in the tooth. Feature creep had begun to set in and new developers using the framework were confronted with an ever-steeper learning curve; as the core of iOS quickly improved, certain parts of Three20 were less relevant. In light of this, the new Facebook for iOS marks our first release in years without the Three20 framework. 

Scaling up with HTML5

As mobile usage exploded over the last few years, our priority was to ensure that regardless of device, platform, network, or region, Facebook users had a good experience on their mobile devices. To support thousands of devices and multiple mobile platforms, we leveraged HTML5 to build and distribute Facebook mobile experiences across iOS and other platforms.

By allowing us to write once and ship across multiple platforms, HTML5 has historically allowed us to keep the Facebook mobile experience current and widely available, and has been instrumental in getting us to where we are today. We chose to use HTML5 because not only did it let us leverage much of the same code for iOS, Android, and the mobile web, but it also allowed us to iterate on experiences quickly by launching and testing new features without having to release new versions of our apps.

So while utilizing web technology has allowed us to support more than 500 million people using Facebook on more than 7000 supported devices, we realized that when it comes to platforms like iOS, people expect a fast, reliable experience and our iOS app was falling short. Now that our mobile services had breadth, we wanted depth. So, we rewrote Facebook for iOS from the ground up (I really did open up Xcode and click “New Project”) with a focus on quality and leveraging the advances that have been made in iOS development.

(Re-)Building for speed

One of the biggest advantages we’ve gained from building on native iOS has been the ability to make the app fast. Now, when you scroll through your news feed on the new Facebook for iOS, you’ll notice that it feels much faster than before. One way we have achieved this is by re-balancing where we perform certain tasks. For example, in iOS, the main thread drives the UI and handles touch events, so the more work we do on the main thread, the slower the app feels. Instead, we take care to perform computationally expensive tasks in the background. This means all our networking activity, JSON parsing, NSManagedObject creation, and saving to disk never touches the main thread.

To give another example, we use Core Text to lay out many of our strings, but layout calculations can quickly become a bottleneck. With our new iOS app, when we download new content, we asynchronously calculate the sizes for all these strings, cache our CTFramesetters (which can be expensive to create), and then use all these calculations later when we present the story into our UITableView.

Finally, when you start Facebook for iOS, you want to see your news feed, not a loading spinner. To provide the best experience possible, we now show previously-cached content immediately. But this introduces a new problem: If you have a lot of stories in your news feed, UITableView throws a small spanner in the works by calling the delegate method -tableView:heightForRowAtIndexPath: for each story in your news feed in order to work out how tall to make its scrollbar. This would result in the app loading all the story data from disk and calculating the entire story layout solely to return the height of the story, meaning startup would get progressively slower as you accumulate more stories.

The solution to this particular problem has two main parts. Firstly, when we do our initial asynchronous layout calculations, we also store the height  of  the story in Core Data. In doing so, we completely avoid layout calculation in -tableView:heightForRowAtIndexPath:. Secondly, we’ve split up our “story” model object. We only fetch the story heights (and a few other things) from disk on startup. Later, we fetch the rest of the story data, and any more layout calculations we have to do are all performed asynchronously.

All this and more leads to high frame rates while scrolling and an app that remains responsive.

New Foundations: Messenger and beyond

Developers always have to deal with constraints. Some are technical, some design, and some are driven by product requirements. We began rebuilding Facebook for iOS while a new native app - Facebook Messenger - was starting to gain traction in the wild. Our challenge was to completely incorporate both the foundations and UI of Messenger, and in doing so take advantage of all the heavily-tested code the messages team works so hard on. When you tap “Messages” in Facebook for iOS, you’re seeing the same code that runs as a standalone app in Facebook Messenger.

To accomplish this we built a system of modules. Modules provide view controllers that are presented when you tap a bookmark in the left navigation menu. News Feed, Messages, Friends—they’re all modules. Modules also specify their dependencies. For example, we use MQTT to update notifications, messages, and bookmarks. At application startup, we walk the dependency graph and ensure that our MQTT service has started before we start listening for new notifications. Even as we add new features, our modular system ensures that our application setup happens in the right place, at the right time.

While modules get us part of the way there, Messenger couldn’t simply move all existing code over to a new core overnight. The new authentication system in Facebook for iOS and the separate implementation that still exists in Messenger use objects that share a common interface (they “conform to the same protocol,” in Objective-C parlance). In conjunction with the Messenger team, we built a dependency injection system that provides Messenger code with the objects it uses to authenticate at runtime. When running as a standalone app, the Messenger code is provided with the Messenger implementations of these objects; when running as a module under the new Facebook for iOS, it’s provided with a different implementation. The code that uses these objects is none the wiser.

Planning for the future

At the moment, stories in news feed consist of headers with profile pictures and timestamps, messages, photos, videos, the “Like” and “Comment” buttons, and a whole lot more. HTML5 allowed us to add these these features and update our designs quickly, such as when we recently updated news feed to make photos bigger. But news feed is constantly evolving, and  building more in Objective-C creates new challenges when we add in new features.

To solve this, we came up with a different plan to let you use the newest features without requiring you to update the entire app: a “fallback” renderer. When the news feed team designs a new type of story, Facebook for iOS downloads something it doesn’t quite understand. When we detect this, we use a “fallback” renderer to show the pertinent information in the new story in a format the app already understands. In the meantime, we create a new custom renderer and have it ready for our next app update. For areas within the app where we anticipate making changes more often, we will continue to utilize HTML5 code, as we can push updates server side without requiring people to download a new version of the app.

The best Facebook experience, in your pocket

Building on native iOS gives us a major opportunity to keep making the app faster, more reliable and feature-rich. Whether you have 30 seconds or an entire train ride to use Facebook we want you to have a fast and satisfying experience. We truly believe mobile is the best platform for Facebook, and the new Facebook for iOS is just one of our steps to ensure you have best Facebook experience anytime, anywhere.  

—————————

My note on this article:

• Have I noticed a difference: Yes
• Does speed matter: Yes 

Goertz Casefilm Virtual Shoe Fitting. Kinect devices scan your feet then render 3D models over your feet in real time.

AUDI CITY: The dealership of the future. Audi City London is a groundbreaking dealership experience delivered by one of the most technologically advanced retail environments ever created. The digital environment features multi-touch displays for configuring your Audi vehicle from millions of possible combinations. Your personalized car is visualized in photorealistic 3D using real-time render technology, making the Audi City vehicle configurator the most advanced in the world. After personalizing your Audi, you can toss your vehicle onto one of the floor-to-ceiling digital “powerwalls” to visualize your car configuration in life-size scale. From here, you can use gestures to interact with your personalized vehicle, exploring every angle and detail in high resolution using Kinect technology.

A Cognitive Burden

Article: Source

It’s hard to blame Microsoft for making bold decisions with its upcoming desktop operating system. But the renamed Windows 8-style UI (or Modern UI) instead of Metro might be too great a departure from known and trusted interactions found in the previous versions of Windows.

According to Raluca Budiu, User Experience Specialist with Nielsen Norman Group, who gave an interview to Laptop Magazine, some design decisions are confusing at best and, at worst, a cognitive burden that slows down the user.

Budiu used to do research in human-computer interaction at Xerox PARC, the very same company that invented the Graphical User Interface and gives therefore a valuable opinion on user interfaces and user experience.

Budiu states that the main problem with Windows 8 will be that users will have to deal with two completely different interfaces, that is to say the traditional Windows desktop interface and the tile-based Modern UI. Not only some interactions will be drastically different in Windows 8, but users will have to keep track of which action to use in which environment.

In addition to piling up two different user interfaces, Budiu believes that the app switcher is problematic. It shows each Modern style app in its own tile but all the desktop apps are regrouped in one tile. Users will have to remember the apps that are currently running in the desktop in order to avoid going back and forth between the desktop and the Start screen.

When it comes to finding a common point between these changes, the Start screen seems to incur Budiu’s wrath. It is both a waste of screen space and unintuitive. The Start menu button is gone and switching between the desktop and the Start screen is not evident at first — the button is hidden in a corner and you must hover to make it appear.

Many of the Modern interface paradigms are taken directly from Windows Phone 7. Buttons are not in plain view and most of the screen real estate is dedicated to content. It should have been adapted more thoroughly to the desktop environment.

The risks for Microsoft are clear. Windows users might retaliate badly to UI changes by using the desktop interface as much as they can. Some will put back upgrading their operating systems. By stating that they won’t offer to boot straight to desktop, Microsoft is courageous. The question now is whether they will be able to stay the course and whether the Start menu is effectively gone forever.

More…

Another article I recently read about Windows 8:
http://www.pcgamesn.com/article/why-i-m-uninstalling-windows-8