jammylammy Just another WordPress site

July 26, 2015

Why you need design

Filed under: Design — admin @ 8:16 am

So much of this excerpt from ‘You’re My Favorite Client’ by Mike Monteiro is great. One quote won’t do it justice, so I’d urge you to read the whole thing (and then buy the book, as I did):

…when we build websites or apps, we often wait until the last minute to bring in designers to “apply” design, or look and feel. This is akin to baking a cake and then hiring a baker to make it taste good.

February 11, 2015

Frere-Jones: Typeface Mechanics

Filed under: Design,Typography — admin @ 8:03 pm

Tobias Frere-Jones has posted the first in a new series of articles on type design. If the rest of the series is like this, I’ll be hooked.

Before I read the article I did not fully appreciate that these nuances existed in something like type design. The parallels with other design disciplines are obvious to draw but most interesting to me is that day to day, the digital, pixel-based world I make my living in posits that if it “is (mathematically) right”, then it follows that “it’ll look right”.

It’s always wonderful to be reminded of crafts that exist outside the digital space where “if it looks right, it is right” is the mantra. It talks to the skill of the craftsperson to know this and — more importantly — to know how to get it right.

January 29, 2015

Paperproto

Filed under: Design — admin @ 9:19 pm

A 3D printable model of a phone that lets you create quick paper prototypes. Great idea!

Don’t Describe A Unicorn Unless You Really Think You Can Cage A Unicorn

Filed under: Design — admin @ 9:12 pm

I come across a lot of job descriptions and their quality varies wildly. The descriptions that exist in the UI/UX contract design community are intended to snare the widest pool of talent possible — from a recruiter perspective, the more potential candidates, the more likely the role will be filled. But this often leads to awkward interviews, where it quickly becomes apparent that your skills do not match the role.

This guide from Google Ventures summarises what makes a good job description. Like anything of value, it takes time and craft to prepare but the payoff is more suitable candidates applying for roles.

How to Make Side Projects Work At A Digital Agency

Filed under: Culture,Design — admin @ 9:06 pm

Spending time working on non-client work is something I believe is key to maintaining motivation within a creative team. Taking a break from client work to spend time solving a completely different problem is mentally and creatively refreshing.

Smashing Magazine have an article on the subject that’s definitely worth a read. From my experience, the biggest challenge to these internal side projects is making it commercially viable. But to only consider side projects in a commercial light is to miss the bigger picture and the greater benefit they can bring to creative teams.

As a contractor, I doubt I’ll be partaking in any side projects during my contract work. I do, however, plan on working on some side projects in my own time.

March 21, 2014

The Frustration of iOS Banner Notifications

Filed under: Apple,Design,Experiential,Ideas,Interfaces,iOS,Mobile,Usability — admin @ 5:18 pm

Sagi Shrieber has written a thought-provoking piece on his annoyance with iOS notifications, offering some suggested improvements as to how notifications appear and how users might interact with them. The whole piece is worth a read but the basic jist is:

  1. Too often, iOS doesn’t get it right when you try to dismiss a notification by swiping it off the top of the screen. iOS interprets this swipe as a tap, taking you away from your current task. (I believe that you actually have to tap & hold the notification, drag it down a little then ‘throw’ it off the top of the screen to dismiss it — not easily done.)
  2. Because of the inherent clumsiness of the dismiss gesture you might opt to just ignore the notification instead and carry on with what you were doing. However, the position of the notification banner over the top of your currently-running app’s UI means that some of the controls of your current app are obscured for the duration of time the notification persists.

So when a notification arrives that you’re happy to ignore, you’re too afraid to swipe up and dismiss it because of the first issue yet you cannot really ignore it because of the second.

Sagi offers a couple of solutions to these issues:

  1. When a notification arrives, pull it down to show the necessary interface to deal with the notification. Once dealt with, swipe up to ‘put away’ the notification and return to where you were. (Note: Sagi’s initial sketch shows this swipe up feature, but his mockups do not seem to demonstrate it).
  2. Position the notification underneath the currently-running app’s titlebar, thereby keeping relevant UI and/or controls relating to the currently-running app visible and usable. So if you want to ignore a notification and keep doing what you’re doing, you can.

Whilst I love seeing other people’s ideas on improving already well established UIs (I’ve done it myself), I can’t help feeling that these suggestions overcomplicate notifications, their associated interactions and app hierarchy within iOS. A banner notification is designed to notify you of something in way that’s unobtrusive, along with offering you a way of ‘doing’ something with that notification — including dismissing it or ignoring it. In a nut, notifications should be simple, obvious and easy to act on or ignore.

Sagi’s piece focuses on a Whatsapp notification interrupting his use of the Homebudget app, so let’s keep going with that scenario here. I have a few questions on Sagi’s suggested improvements:

  • When I pull the notification banner down to load the Whatsapp interface, am I in the Whatsapp app or still in Homebudget? This is important when considering how I exit the Whatsapp interface to get back to what I was doing in Homebudget.
  • Considering the above, how do I get back to Homebudget? I want to be able to slide it back up to get back to Homebudget — the reverse of what I did to get into Whatsapp. If I can do that, where’s the affordance in the Whatsapp ‘sheet’ to tell me I can do this? And if I can swipe up to dismiss the Whatsapp interface, how will iOS know whether I meant to dismiss the Whatsapp interface or whether I wanted to invoke Control Center, also available by swiping up from the bottom of the screen?
  • If I can’t swipe the Whatsapp UI off the top of the screen to get back to Homebudget, how else do I get back? Double-tap the home button to show recently opened apps and select it from there? How is that any less annoying than what happens today?
  • Because the notification now sits within the content of the currently-running app — underneath the title bar — how will iOS know whether I’m trying to dismiss a notification or scroll? Granted, this is a challenge that applies to the current implementation of notifications (and is, perhaps, a reason why dismissing them is so hit & miss).
  • Is showing the notification underneath the title bar really a better solution? Whilst it avoids obscuring any controls residing in the titlebar, it’s still sitting over the top of content I was looking at. A notification over the top of a photo you’re about to post or a tweet you’re about to send is still in the way. (In either of these two scenarios, I’d most likely try to dismiss the notification before continuing with what I was doing, regardless of whether it obscures content or controls. It’s still in the way.)

I completely agree with the issues Sagi highlights. Dismissing a notification is currently a game of pure luck; the number of times iOS has misinterpreted a dismiss gesture for a tap is far larger than the number of times it’s been able to get it right. But as I was reading Sagi’s piece, it struck me that perhaps a better interaction model for notifications already exists in iOS: those that are shown on the lock screen.

A mockup of an iOS banner notification being swiped to the right

What if, when I receive a notification, I were able to ‘action’ it (read, reply, post etc.) by swiping the icon to the right, as I do on the homescreen? This would take me off to the app that invoked the notification. It’s fairly safe to consider this gesture as something relatively ‘bullet-proof’, in that there’s no mistaking what I want to do if I swipe.

Tapping the notification would therefore do nothing. Swiping to dismiss the notification would therefore be a whole lot more accurate.

Also, what if we let iOS assume that when I receive a notification but carry on interacting with the currently-running app, that I do not want to action it just yet? The notification arrives, I continue tapping or scrolling in the app I’m in, so iOS hides the notification as I’ve made it clear I’m in the middle of something. If I do want to do something with the notification, I can pull down Notification Center to see it and action it from there.

We could take this further and say that swiping an icon invokes an ‘inline’ or contextual interface to let me action it, much as notifications on the desktop in Mavericks does. The notification arrives, I swipe the icon, but instead of taking me to Whatsapp, I get a modal box (like the one Sagi mocked up in his piece) that lets me reply to the message without taking me out of Homebudget. Importantly, it would also let me ‘cancel’, so if I changed my mind and didn’t want to reply immediately, I wouldn’t be forced to do so by a limited UI.

To me, these interactions fit with the notion and purpose of banner notifications much more comfortably.

Sagi’s post really resonated with me and sparked a lot of internal debate, so none of my comments or questions are meant as a negative critique of his original point and subsequent ideas. I wholeheartedly share his frustration with iOS notifications and refuse to accept that there’s not a better way of doing them.

Perhaps that’s why, after reading his post, these ideas have been tumbling around my head all day.

Thanks for the inspiration, Sagi!

September 6, 2013

The New Yahoo! Logo

Filed under: Design,Opinion — admin @ 1:27 pm

There’s so much greatness in this post by Oliver Reichenstein on Yahoo!’s new logo:

Redesigning a logo for a $10 Billion Dollar company that is in deep trouble is not a matter of talented designers and personal preferences for design. It is not about fiddling. Doing it in a weekend is simply unprofessional.

My favourite bit by far is this gem, relating to the ‘mathematical consistency’ piece of Marissa Mayer’s blog post announcing the new logo:

Perfect geometry does not result in perfect design. On the contrary, “real visual rhythm is hurt by precision. This fact is where we get the saying in design: if it looks right, it is right.”

Personally speaking, I mourn the loss of the old Yahoo! logo. The new one is devoid of any character and, having seen the efforts put out during Yahoo’s 30 days of change, feels like it boiled down to a choice of typeface.

All Mayer’s bullshit does is sprinkle glitter on a turd. Terrible, transparent, waffly, tack-it-on-once-we’ve-artworked-it-up glitter.

June 19, 2013

Michael Heilemann’s Thoughts on iOS 7

Filed under: Apple,Design,Interfaces,iOS,Usability — admin @ 2:01 pm

Michael Heilemann has some thoughtful posts on some of the UI changes in iOS. I’m posting them here primarily because they make a lot of sense to me but also because I want to see how the final product compares to the Beta.

I haven’t used iOS on any device — I’m not part of the developer program — so only have critiques like Michael’s to go on. It appears that there are some fundamental changes to how you interact with the OS that seem careless — even thoughtless. As Michael says:

However, when I look at a beta I see anti-patterns and basic mistakes that should have been caught on the whiteboard before anyone even began thinking about coding it. I get scared. This isn’t a matter of ‘oh, it’s a little glitchy now and then’; these are things that from the looks of it seem simply like poor design decisions.

Here are the things I see as issues with the iOS 7 Beta. It’ll be interesting to see which ones are resolved by ‘this fall’.

  • Circles for signal strength — as Michael and many others have said, this breaks a fairly widespread standard, takes up precious horizontal space, uses the same UI element as pagination and seems to be solving an issue that just doesn’t exist for many users — we all know what those bars at the top of our phones mean.
  • Affordability of controls — I see lots of ‘text as buttons’ in the iOS screenshots I’ve seen. How do I know whether something is a label or a control? And, as Michael says, what issue is this trying to fix? Seems like minimalism for the sake of it.
  • Swipe right on the whole lockscreen — this one shocked me the most. Apparently, you can now swipe right anywhere on the lockscreen and it’ll unlock the device. This doesn’t seem pocket-friendly at all. I also wonder how much of an effect the removal of the UI controls for this gesture will impact the usability & obviousness of the gesture. For example, my 15 month old daughter is able to unlock an iOS device. She knows that by moving the drag handle near the bottom of the screen to the right, the device unlocks. All the affordance that informs & reassures her about this gesture is gone in iOS 7. It’ll be interesting to see if she can still unlock my iPhone when I install the OS later this year.

Yes, yes, it’s a Beta, there are bound to be some glitches. And there’s plenty of time to fix & improve before the OS is released. But I have to agree with Michael — some of these things are just bad design decisions.

I’ll revisit this post in ‘the fall’. Or Autumn, as we say around these parts.

October 23, 2012

Rethinking the App Switcher

Filed under: Apple,Design,Usability — admin @ 9:47 pm

Earlier this month, this redesign of the iOS app switcher garnered a lot of press.

I love almost everything about this idea with the exception of one thing: by using screenshots instead of the app icon I find it much harder to figure out what the apps in the switcher are.

iOS has always used icons to represent apps. The recognition of these icons is key to identifying apps, both on the homescreen and in the switcher. By using screenshots of the apps instead of icons, that link is lost and, for me at least, any benefit in seeing what state an app is in is far outweighed by the additional cognitive load placed on me to try and identify an app.

Yes, the name of the app is shown underneath the icon. But for sheer glance-ability, and for me, icons are a much better solution.

July 11, 2012

It’s about tomorrow, not today (or yesterday)

Filed under: Apple,Design — admin @ 10:58 am

A few days ago Marco Arment tweeted:

If you’re a web designer, you really, really need to get a Retina MacBook Pro so you can see how bad your site looks on it and fix it.

To which Anna Debenham retorted:

If you’re a web designer, you really, really need to get a cheap Dell monitor so you can see how bad your site looks on it and fix it.

A cute reposte but one that kinda misses the sentiment of Marco’s original tweet. In a follow-up post on his blog, Marco explains the rationale behind his original tweet:

Even though it’s [the high-DPI market] a small market today (although don’t forget about the iPad 3), it’s inevitably going to increase substantially in the near future. Don’t you want to get ahead of that? Do you want your site to be ready the first time someone views it on a Retina screen, or are you OK with it looking like garbage for a few years until you happen to buy high-DPI hardware?

Which further explains — to those who thought his original tweet was misguided — his rationale, one that I totally agree with. To suggest viewing designs on a poor monitor should be part of a designer’s workflow is looking at how things are today. Marco’s tweet was surely intended to get designers thinking about tomorrow.

There are things we, as designers, can do to make sure the digital solutions we create look great on these new high resolution displays. There’s little we can do to improve the experience of someone viewing our site on a ‘cheap Dell monitor’ that’s over & above what we normally do, such as ensuring sufficient colour contrast.

As happened with early versions of IE, there’ll possibly come a time where we don’t cater so much for low-DPI monitors. Design solutions will consider high-DPI displays ‘the norm’. We’re a good few years away from that, most definitely, but you have to believe that Apple will expand their product lines to include retina displays over the coming years. And it therefore follows that some — maybe not all, but some — PC makers will start producing high-DPI displays.

Older Posts »

Powered by WordPress