Styling File Inputs in iOS6 with jQuery Mobile
File this post under: “stuff that’s in obscure forum posts but not really documented well”. As per a previous post, iOS6 brought about access to the camera in Mobile Safari. While access is not real time (getUserMedia would be amazing), we are able to prompt the user to take a new photo or access the camera roll. Presumably for security reasons, styling file inputs in desktop browsers has always been hell on earth. Mobile is much the same.
What you can do as a work around is rely on native browser functionality where clicking a <label> triggers the clicking of it’s associated <input>. I’ve relied on the native jQuery Mobile button styling for speed, but you can achieve pretty much anything. Hiding the input can be achieved in various different ways, but as far as I know it cannot be display: none; for security reasons. Setting visibility: hidden; or opacity: 0; will all achieve the same effect, and setting position: absolute; will take it out of the page’s flow.
You can see it in action in the JSFiddle below.
More Form Failures
In the post directly below I discussed the ramifications of bad form design on the overall customer experience. I compared Telstra’s woeful forms to those of The Commonwealth Bank of Australia, and how even a lethargic bank is beating them in the form stakes. Oh how I was wrong.
Unlike the Telstra forms, the Commbank forms do accept ‘space’ as a character. Transactions descriptions have all kinds of horrible length and character restrictions, but I can live with that. The main qualm is that while the account number and BSB fields accept spaces, they still have maxlength requirements that will trim the last few characters off your pasted value silently. No validation error. No automatic removal of spaces. Nothing.
You could argue that it’s my responsibility to check and compare the account number in the confirmation step. I would generally side with you, but I honestly feel that copy and pasting a value from an email, well, I take it as gospel and I’m sure I’m not alone.
How this differs from the Telstra examples (contributing to an overall shit-house experience) is that this mistake actually costs you money. No-one likes paying bank fees, especially when they have all your money to bet (and lose) already, but this form failure will result in an incorrect transaction and a $2.50 account fee.
Be careful. Bad form design can cost you and your customers money.
An Autopsy of a Bad User Experience
I’d like to take a moment to share a bad user experience with you. Why? I believe it’s important to diagnose the how and the why whenever these issues occur. It’s one thing to feel empowered by social media and sound off your 140 characters of fury. But what does that achieve? How do others learn from these mistakes?
To try and explain what a user experience designer or developer does is not an easy task. Some even contest the field’s right to exist, comparing the UX crowd to SEO specialists and their fellow snake oil salesmen. But for the sake of the word count, I’ll attempt to distill a large part of what UX means to me, into a single key quote:
UX is all about reducing friction.
- Andrew Fisher, @ajfisher
That’s it.
Friction as in, having to fill out unnecessary information. Having to repeat yourself. Reading lots of instructions. Specify a value that should be a default. Unnecessary points of contact. Email activation. Inefficient and inaccessible CAPTCHAs.
We’re taught as programmers to be DRY (don’t repeat yourself), so why must the user repeat themselves? Being pre-emptive. Being presumptuous. Terrible ways to spec and build software, but critical in a user’s path. Speedy processes are, after all, about reducing friction.
But back to the issue at hand: a terrible user experience.
I recently moved to Telstra. For the international readers, Telstra is kind of what you move onto when you’re no longer a tight-arsed teenager and want a telco that actually works. But if you plan to sign up or interact with a Telstra service at any point, the path is unfortunately predictable. Either an online form or the legacy system behind will trip you up. You will receive an unspecific, confusing error. You will call Telstra. The lovely call centre staff will fix the problem. The form or system will remain broken. Repeat.
The flaws in the workflow are plain to see:
- The forms themselves are littered with usability and accessibility issues
- The user is not given a descriptive error or instructions to rectify an error when it occurs
- The user is encouraged to call a 24/7 call centre instead
- The call centre staff spend their time fixing relatively straight forward issues
- The form remains broken
The issues I experienced became largely apparent when I was getting overdue bills that I simply couldn’t login to pay. I had difficulty beforehand getting into the system, but now I had a real financial motivation. I won’t go into the problems I experienced pre-ordering the iPhone 5. That form was presumably cobbled together at short notice after the phone was announced. That doesn’t excuse the number of problems I experienced, but see the workflow above for a short summary of how I negotiated those forms.
Maxlength everywhere and the ‘Space’ key is forbidden
So whenever you see your account number mentioned you will notice it’s neatly broken up with spaces. This was probably done because it makes it easier to read aloud to a call centre operator when you inevitably have to speak to one, but I digress. Almost everywhere you need to enter your account number, you might attempt pasting it in directly from the email.
Paste it in. Fill in the rest of the details. Hit enter.
Oh damn. The spaces are forbidden characters.
Remove said spaces. Hit enter.
Oh now I’m getting an error (depending on the form, it may actually be helpful and tell you that your account number must have one of three numbers of characters). Eventually you’ll work out that there’s a maxlength on the field and the last two characters of your account number are always trimmed.
Sidenote: I noticed the other day that even the Commonwealth Bank is schooling Telstra in this area. Yes, a bank. Come on guys.
Your username is not your username
Just in case you ever have trouble logging in (you will), it’s worth remembering that your username is not actually your username.
Confused? Don’t be. Try a “forgot my username” email.
Oh great, I thought that’s what it was. Maybe I’ll try resetting my password while I’m at it.
Oh, I see, the label on the left is wrong. It must want my email instead.
FFFUUUUUUU—.
Sidenote: Don’t even get me started on the non-standard <select> elements they use when asking for your date of birth.
Double sidenote: I was 99.999% sure of what my username and password were, and the system isn’t letting me in.
It’s not like the underlying systems are any better
I enjoy re-telling this story. I couldn’t pay any of my bills because I couldn’t create an account. And I couldn’t create an account because the system hadn’t created my “account”. That’s when this lovely exchange took place over the phone.
Telstra: Sir, your account could not be created because the system is missing some key information such as your date of birth. Could we have it please?
Me: You mean the date of birth I just gave you to verify my identity?
Telstra: … Yes.
Me: ………….. Okay, sure it’s XX/XX/XX
Did I mention the system failures?
If you’ve jumped through enough hoops you might finally get to the point where you have an account set up, you can log in to it, and you can finally pay your overdue bills (did I mention my service was suspended?). This is when the call centre operator (who was great mind you), will inform you that the payment cannot be processed because the direct debit systems are down. He’ll call you back tomorrow.
Inconsistent inline errors and error pages
This is always going to be a problem in large sites with multiple forms. Depending on when a form was created (and by who), some will employ inline JavaScript validation, while others will use server-side validation. It’s inconsistent, but not nearly as frustrating as the vague error pages you will be sent to. These pages leave you stuck in some kind horrible purgatory in which you iterate through each field making minor changes attempting to correct that vague error. Eventually, with no feedback, you will most likely give in and call that lovely, shiny 24/7 support line and they explain it away as something wrong with their systems and correct it manually.
As of right now, I can’t log into the Telstra My Account area because my username and password are “incorrect”. I find this quite funny, because they’re coming from the Chrome Autofill tool and were working previously. Perhaps my account has been locked after too many incorrect attempts? But of course, I’ve got no way of finding out because the system doesn’t provide any user feedback. Then again, I could call that 24/7 support line…
A freebie: Pre-filling Information
In the opening paragraphs I reiterated some of Andrew Fisher’s thoughts about building frictionless experiences. In part that can be expressed as “why ask for information that you already know?”. It’s not critical, but I’ve always been frustrated how something as simple as the “state” field cannot be inferred by GEOIP lookup, or at least persist across steps. Every state field in the system that doesn’t come directly from your account settings will default to NSW. If you change that in step 1, and go to step 2 where you need to enter billing or shipping details, that state has also been set to NSW by default.
The vast majority of sites are guilty of this, but it still shits me to no end.
Justification
So who am I to tell the largest telecommunications company in Australia how to run their business? Well, I’m an end user who experienced some pretty glaring issues, for one. On the other hand, I know my way around a computer, and I can build a website or two. So spare a thought for all the people that aren’t even remotely technical. The people that weren’t able to figure out the maxlength on the account number field was set too low. The ones that don’t understand why a ‘space’ character isn’t numeric. These are sometimes the delightful kinds of people that dial the call centre to give the staff an absolute spray, for experiences they have no control over but must answer for.
Corrective Action
So where to from here? Someone within Telstra desperately needs to take ownership of the forms and the conventions around them. Setting guidelines and defining expected behaviours would go along way towards fixing the mess on the front end at least. I hold zero hope for the legacy back end systems being fixed any time soon, so this is where some neato JavaScript code adds value by acting as a middle-man. User input in, middle-man code, sanitised code into clunky old forms.
Corporations of Telstra’s size (eg: banks) are notoriously silo’d and the speed of change approval can be glacial. At a guess, I’m assuming there are multiple product owners within Telstra that these forms span across - so hopefully some of Telstra’s newly appointed UX leads can internally champion the cause and act swiftly.
Evidence based decision making and rigorous testing play a large role in ensuring change is effective. Tracking the occurrence of form failures and validation errors, as obvious as it seems, would reveal when your form is simply too hard. Drilling down as granular as possible, you may find that end users are having difficult with one field in particular. Perhaps the validation rules around account numbers are generating too many inline errors. Perhaps responding to that might have precluded this whole blog post?
I can’t tell you whether what I experienced was a bad user experience or instead a negative customer experience. But what is important is that these experiences are tied perilously close to the overall perception of the brand. It’s one thing to establish a “tone of voice” or enforce a style guide, but in a digital world, these points of interaction are just as important for representing your company and it’s priorities. From what I’ve seen to date, it appears that UX is not one of those priorities.
Great concept. Be sure to watch the video as the text just doesn’t do it justice!
Flick Scrolling
You might wanna watch the video above, but in short: When scrolling content on a touch-screen, instead of letting momentum stop the scrolling, you can decide exactly where it should stop. It stops at the point where you flicked it.
It would be great for things like books, blogs, timelines or anywhere where you don’t fly over, but continuously wanna “move forward”. Kinda like paging but within and long scroll. Some apps have a page up/down feature, but I don’t really use it because it moves always the whole height and might cut off a picture or so. With this “flick scrolling” you can decide to where it should move to. The last paragraph or beginning of a picture.
Why not just use pages or cards? Yes, that works sometimes, but not always, especially not when you have no control over the content. iA wrote a good post about it: Scroll or Card? With flick-scrolling you get the joy of “card flipping” without the cards.
Here the two demos from the video so you can try it out (only tested on iOS).
Warning: I’m not really a programmer so the demo is just a hack to demonstrate how it could work. Would need some improvements. And of course, performance would be better if it would be implemented natively.
One thing I’m not sure about.. there is the possibility that you intend to do a flick scroll but end up doing a normal scroll or vice versa. You can judge for yourself in the demos. Maybe the detection could be further optimized or here some other possibilities (Let me know if you can think of more).
- Use a two-finger scroll. But then you can’t use just your thumb which makes it not that useful.
- Split up the screen into two areas, for example left for normal scroll and right for flick-scroll.
Credits: Demos use the iScroll4 library and in the timeline demo, the “scrollToElement” feature is used, which is a pretty cool one.
UX Lab 10, 11 & 12
Here’s a bulk upload of three UX Lab experiments. I’ve been pretty busy, but these are ideas I’ve had for a long time and have been kicking around on my hard drive to some extent. I thought I’d better get them out and about.
UX Lab 010 - Blurred Modal Backgrounds
Modal dialogs are used in preference to regular popups because they generally disable interaction with the page behind and guide focus to the new window. This is achieved by visually obscuring the content behind the modal, but not so much that the two seem disconnected.
As long as people have been doing this, the have been attempting to blur out the background to greater magnify the effect. It hasn’t been possible without the use of non-dynamic PNGs, Flash or some other form of hack. Now that Webkit-based browsers are supporting the CSS filter property (not to be confused with the IE legacy one), the sought after feature is now possible.
The linked demo guides focus in two modes. One blurs out all background elements, the other desaturates them. Unfortunately there is no support for animation of these properties, so until that is implemented the effect is a bit blunt.
UX Lab 011 - Flipboard-style Notifications
I see notifications similar to these throughout iOS and OS X applications everywhere. I like the way they demand a bit more attention than your normal jGrowl, but still aren’t too impactful.
Maybe I’ll fork these properly into their own GitHub repo. Maybe I won’t.
UX Lab 012 - OS Dependent Modal & Close Buttons
This is something I thought of a long time back, and has been live in Kiandra IT development template for a while now. It’s frustrating that on the web, OK/Cancel button order and close button placement are all decided by the designer/developer. I remember a while back when a notable ex-Apple designer more or less told Dan Cederholm the close/delete icons should be on the left for everyone. Sure, there are probably more Macs and iOS devices on Dribbble than Windows - but it’s still pretty inconsiderate to force that upon the entire audience.
A UX guy once explained to me that the OK/Cancel placement on a Mac had a lot to do with the linear direction of the workflow. The OK being on the right, as it advances you another step to the right in a wizard. I remember the Windows placement being that you read the desired action first, and that’s the most important. After a bit of research, it appears Jakob Neilsen summarised it quite nicely..
But the little Mexican girl in me says:
It’s not even remotely difficult to implement technically, and shows you’re willing to compromise. Exhaustive studies may one day show one method to be “better” than the other, but until then, don’t be a dick about it.
bootstrap.footnotes.js - UX Lab 008
I love the Instapaper-style footnotes/endnotes that came about with the last major update. Here they are in web form, as a jQuery/Bootstrap plugin. Unfortunately there’s a dependency upon Bootstrap CSS/JS, but such is life. It’s retina ready too - as everything else should be these days.
Here it is in action:
Documentation and options are available on the demo page.
It also has its own GitHub repository.
3D Accordion Effect - UX Lab 006
I posted the following experiment as a way of demonstrating just how far the line has blurred between web based animation and OS based animation. I saw Dribbble shots (one and two) by Indian designer Pranav Pramod and was inspired to replicate the effect in CSS3.
Unfortunately nothing is ever as easy as it seems. If it was, someone else would have already posted a similar effect. The problem is that when animating something with a 3D transform with a forced perspective, there is no way to measure or mirror the actual height represented in the browser using CSS. If you animate the parent element from 0px in height to 30px, it’s a straightforward linear animation. The 3D transform, on the other hand, changes on a non-linear scale because of the perspective.
There are two solutions, neither of which are desirable.
The first involves JavaScript, which frankly I had tried to avoid. In this example, the animation is triggered by the addition of a CSS class via JavaScript - but could just as easily be bound to an :active:target CSS event. The only way to get the actual browser rendered height of the element is to get it via JavaScript with the obj.clientHeight getter. While discussion pointed to wrapping the object in a parent element and not needing JavaScript at all, this does not work in all browsers.
Instead the JavaScript method involves binding a function with requestAnimationFrame which sets the parent objects height to mirror the calculated height of the transformed object. Accurate, but if we wanted to perform calculations many times per second, why did we bother animating with CSS at all?
The other method, considerably less accurate and very fiddly, is to match the easing or timing of the two animations. It may be possible to create a custom timing function using cubic-bezier which matches the rate of easing of a 30px tall object, rotating from -90deg to 0deg, with a perspective of 400 units. But why would you? That’s shit house.
Maybe in this instance a flat out Canvas animation would have been much more sensible. You’re still performing a function every ‘x’ milliseconds, but at least the canvas itself may be hardware accelerated. Until CSS animation matures, we will most likely have to abuse the JavaScript add-ons such as the one described earlier. Or even better yet, sever the ties with HTML and CSS and - get this right - use graphical languages for what they’re intended.
Ninja Edit: Also, you can’t yet animate background gradients so the whole 3D effect on the depth of the flaps is kind of impossible for now.
Sad-face Edit: The second I posted this, someone posted pretty much the exact same thing to Hacker News in a much more polished way. Check out Paperfold CSS.
Idle jGrowl Re-routing - UX Lab 004
Paul Irish wrote a pretty chill script back in 2009 for detecting when a user becomes inactive. It’s quite ingenious in its simplicity, as the best things usually are. What wasn’t explained fully is the ways in which this can be used to deliver a better user experience. It’s fantastic for preventing timed or asynchronous actions when users aren’t going to benefit from the action.
This quick little experiment is aimed at demonstrating the concept in the simplest form.
A jGrowl notification triggered every ‘x’ seconds, or by a server event, isn’t of much use when the user isn’t around. They disappear after a few seconds. So instead, if the user is deemed inactive, you should make them “stick” or push them to a modal, similar to the loathed Growl notification rollup pictured below.
Obviously the linked example isn’t quite as eloquent, but it’s not like the Growl rollup was that well received to begin with. See what other cool shit you can come up with.
I’ve just pushed some major changes to my front end development guidelines to the public site. I spent a lot of time on this update, and it shows. I’ve added new content and improved old. I’ve ditched my own slap-dash styling in favour of the Twitter Bootstrap with some of my own personal tweaks. Be sure to check it out.
I’ve added some sections on:
- The importance of understanding the box model (CSS)
- Knowing when to float, and when to position (CSS)
- Generating unique IDs without timestamps (JS)
- Preserving middle mouse click functionality (UX)
I also:
- Made the website work without JavaScript enabled
- Cleaned up the overall design and interaction (Bootstrapped!)
- Re-wrote some content here and there
- Added pretty graphics to explanations
- Added some resources to the list
Basically, we’ve gone from this:
To this:
Dynamic Credit Card Type Selection - UX Lab 003
If you find yourself buying a lot of things online, or perhaps building a lot of eCommerce websites - you will have experienced a range of credit card forms. The good. The bad. The ugly. Some fields are required to pass security checks. Some seemingly exist only to frustrate you. But what seems constant is the lack of innovation over the years in what is a staple in eCommerce design.
One example that does it really well is the purchase page for Coda, by Panic Software. Not only does it auto-select the card type of the credit card, but it also updates the select button with a background image indicating progress. The only downside I can really find to the Coda page is that when the card image changes, it’s not sprited so you see a flash of white as the images load.
Using a list of prefixes published to Wikipedia, it’s possible to identify nearly every card type in the world. This opens a host of possibilities to designers, like this:
“CC Rebound” by Ryan Rumsey
Not shown in this demo is the ability to isolate the first two or three characters, to further narrow the type of card. How would you differentiate between Diner’s Club (36) and American Express (37), both starting with ‘3’? Using substr(). The rest is up to you.
Introducing the UX Lab
The lab is a place for me to share my thoughts and experiments with the web development community. While the name indicates a user interaction and user experience focus - I’ll also be sharing CSS3, JS and HTML5 tidbits. My aim is to make the web a better, more consistent place. And what better way to achieve that than by leading by example.
The experiments will be hosted as one main repo on GitHub. That way you can easily view the code, download any resources, as well as forking or branching it for your own purposes.
Some of the cool things to come:
- Credit Card Type - Passive Selection
- jQuery UI Slider Toggle Switches
- Mac vs. Windows Close Buttons
- Flash-free Google Analytics
- and more…
iOS eBay: The Good, The Bad, The Ugly
Mike Rundle, author of Design Then Code, is a firm believer in an iOS application being a pixel perfect representation of a company’s branding and unquestionable design. He can be a real stickler, calling out poor design or UX conventions on Twitter and just generally being a loveable prick about it all. But every so often he does stop and remind us that there are real people behind these decisions - and that things are often beyond their control.
The people responsible for the eBay iOS applications care enough about their product to trawl Twitter looking for whingers like myself. And they’re not just looking to mitigate complaints, they’re keen to hear feedback and where people think they have room for improvement. They were sure to pre-empt criticism by stressing that the original application was rushed out in only 5 weeks.
Okay, you caught me out. I was more keen on using the “Good/Bad/Ugly” metaphor than actually thinking up reasons why both the iPhone and iPad eBay apps are “Good”. They both do some pretty cool things (barcode scanning, being more picture/gallery oriented than the website), but that’s not really what this post is about. This post is more about where the apps fall flat on their face.
Branding and Consistency
The only thing marketing experts love more than cocaine is “synergy”. But what the iPad app delivers is an icon and UI different to that of the iPhone app, and eBay’s branding in general. I’m not entirely sure what page in the styleguide the blacks and deep greys come from, and for some reason it really irks me. I think eBay’s marketing department may have overlooked the inconsistant approach for the sheer joy of being able to say they have an iPad app. It was, as mentioned, rushed out in only 5 weeks.
Considering the difference at the simplest level, picking up an iOS device and trying to flick through screens full of apps to quickly locate the eBay app can be difficult. It’s hard to remember that, for example: “oh, I’m on an iPad now, I should be looking for a grey icon, not the yellow one, silly!”
In fact the icon differences just draw attention to the fact that the two apps are presented separately in the app store, and not part of a universal application. Dropbox, Twitterific, Instapaper. These popular apps, free or paid, all have universal installs. I can’t imagine the eBay code-base being very different. Merging the two would even avoid inconsistant language and interaction between the two, like refining how far an item can be from your location:
eBay Mobile - “Local Search”
eBay for iPad - “Max Distance”
Design Treatment
Frankly, I haven’t seen diagonal scanlines used in web or app design since the early-00’s when I was abusing them too. I really can’t understand why eBay pushed an update that replaced the original simple graphics with dated scanlines. Subtle Patterns is a brilliant website for discovering and previewing modern designs of tiling patterns. All of which are free. They’re rich and tactile. They’ll date just as quickly, but scanlines already have a head-start.
Odds and Ends
There are also a few less critical odds and ends that need cleaning up. Prioritisation in lists could do with some work. As a category, “Won” probably is third-most important in the following view. But when the proceeding categories are empty, is it still relevant to show them at the top of the page?
In terms of showing when refinements have been applied to a search, the iPad app takes the better approach. Normally black buttons turn blue when criteria are applied. The iPhone app uses text instead, with a lazy check/square root symbol.
iPad App - Normally black buttons become blue
iPhone App - Text only indication
Also strange is the way in which setting a price range is not enough to trigger the refinement indicator in the iPad, while the search radius is.
There are also plenty of other little bugs and enhancements, but no app is perfect. The inability to enter a landscape keyboard mode in the message centre could probably be fixed and pushed out quickly. The caching of gallery images when flicking between items is probably just as straightforward. These are less UX issues and more programming bugs.
Breakable Workflow
It’s far too easy to get to a point in your search where you can no longer get back to your results, or preserve your refinements.
For me, one of the most interesting functions I can perform on eBay is to view a sellers other items. I’ve done this countless times on eBay and Gumtree (an Australian Craigslist), and it can result in beautiful things and some absolute bargains.
If you were to click “View Sellers Other Items” on the iPad app, you can kiss your search results goodbye. This is incredibly frustrating when you’ve spent time narrowing your search with refinements. I want a road bike. Only from the cycling category. Within 100km of where I live. Only the recent listings because I’ve seen the rest. You might find a cool bike, but the size isn’t right or it’s already well outside your price range. The seller mentions they restore bikes, and suggests you check out their other items. Maybe you’l have some luck there? Boom. Search results, refinements and position gone. No back button. Start again.
Oddly enough I just noticed this only happens on the iPad app, the iPhone app remembers exactly where you came from. Another reason to merge code bases.
Can’t Refine Location Unless Logged In
All iOS devices at this point should be able to geolocate themselves, regardless of 3G connection. Apple and Google are both conducting some wizardry where they can pinpoint your location based on Wi-Fi signal alone. But unless you have an eBay account and you’re signed in, the eBay application gives you no way to filter search results by location.
Even mobile Safari has been able to request your current location since 3.0 with a simple JavaScript call:
navigator.geolocation.getCurrentPosition
The user is offline, or Safari can’t determine the location of this particular Wi-Fi router? Store with window.localStorage and it will persist between sessions. Simple.
What appears to be a fairly straightforward issue to resolve can be immediately attributed to reviews in the app store:
Can’t Update Location When Travelling
Travelling overseas or even interstate will not search where you are now located. This can be directly attributed to the apps reliance on the user’s location listed in their account profile, and not the device’s geolocation. While definitely an edge case, it would also be resolved while addressing the above issue.
Overall
I think that my personal frustration stems from usability issues that could be handled better as a mobile web application. That’s not to say I would ever suggest that eBay goes down the path of only offering web apps. Native will ALWAYS trump web facsimile. But with that being said, if you know that performing a particular action will always break your workflow - you get used to opening that link in a new tab. There is no quick native fix for that. A desktop-sized web app can become a mobile-sized app with a few lines of responsive CSS. There is no quick native fix for that. Merging code bases will be fiddly and time consuming.
Bugs take time to identify. Bugs take time to fix. Submitting to the App Store for a review and update takes time (and isn’t guaranteed to pass). As we speak there are probably similar items as I’ve described, logged internally for eBay’s development teams. But as I’ve discussed, there is no end user work-around for some of these issues - while there would in a mobile app. eBay still offers both, but it highlights a flaw in the native vs. web app argument.
I hope that the product owners and dev teams can take some of what I’ve said on board. This isn’t unwarranted criticism. Staff at eBay have expressed a desire to learn more about what UX people like myself think they can improve on. Here’s to a better UX for everyone.
A behind the scenes look at Mill Touch. There are some amazing concepts going on with this device, aside from bringing the Minority Report concept to life. I particularly love the overlay where you can see the pre and post productions at the same time (around 2:55).
I never knew the team at Mill were behind so many incredible commercials. Nike. Old Spice. Skittles. Budweiser. Various super bowl ads. Here is their 2011 showreel and their more recognisable 2010 showreel.
Hi, I'm a UX Developer - You're a What?
I showed this to my computer-illiterate girlfriend a while back to help her understand what I do for a living. While broad articles like this are never going to describe every person, perfectly; it did ring true in a few regards.
A really good read. Recommended.
