Better surfacing of content

The new Chrome Web Store dramatically simplifies navigation to three options: scroll the current view, click on one of the categories or search. This is a significant improvement over the old store where the page contained a lot of chrome and was broken up into many sections, like “Apps”, “Extensions”, “Featured” and “Popular”. Now the page just shows you content, and the left-hand navigation bar has categories, including “Popular” and “Collections”, which seems clearer to differentiate between than featured and popular. Also of note is that the store no longer tells you about the difference between extensions and apps – they’re all apps now, which is a step away from the namespace popularised by Firefox and its extensions ecosystem.

More content in the same amount of space

Although the old store gave each item a lot of room, the new one reflects Google’s new taste for compact, minimalist design more closely by only showing apps. Each app is represented by a banner and a little footnote with its title and some stats like how many users it has or what its rating is (this appears to vary depending on which list you’re looking at, something they’re probably experimenting with).

Banners everywhere instead of icons

Scroll down a bit in Utilities and what do you see?

While the original Chrome Web Store mirrored the design of Apple’s iTunes Store quite closely, the new Web Store follows its own path with banners of varying sizes representing apps in most places rather than icons. This works well as it increases the density of information you get about each app when you see it in a list, allowing you to decide whether you want to click based on a larger number of signals than what an icon can offer you.

Clear banner guidelines for app developers

Before launching the new store, Google contacted every app developer and let us know that we’d have to upload new banners to represent our apps in the new store. One of the guidelines was that the banner had to be big, bold, and use little text or miniscule details. This recommendation paid off, because now when you scroll through the store, you see exactly that: lots of big, bright, bold app names, with a little branding to set them apart and give you an idea of what they do. You can upload three different formats to represent your app, which comes in handy when you get featured by Google. “Getting featured” means either being displayed at the top in a huge rotating banner, or being displayed in a somewhat larger size than surrounding apps anywhere in a list.

More focused display of individual apps

How apps are displayed in the new Chrome Web Store

The old layout for app pages was good, but the new one makes it clear that it could be better. It suffered from the same problems as the rest of the store: a lot of up-front information you don’t necessarily care about when looking to install an app. As such, the new display solves many of those problems. It loads faster since it’s now an inline overlay rather than a separate page. Reviews and extended details are hidden in separate tabs, allowing the most important details to immediately stand out. And since banners are now separate – banners being used to display the app throughout the store – screenshots, which are now also a lot bigger, get front and center attention whenever you click an app. And then there are lots of other small tweaks, like reducing the contrast and size of some text while making the “Install” button much more evident.

Final thoughts

Overall, the new Chrome Web Store is a huge upgrade in terms of usability for people looking for apps and discoverability for people who make apps. The increased density of content coupled with the simplified navigation and faster experience overall makes it (almost) unsurprising that Handcraft got over 7000 new users in just under a week. While the first iteration of the store was a great starting point, this design really reflects Google thinking for itself and designing for its own problems. Now the question is how our signup rate will be affected as the store loses its freshness, and how engaged people who sign up for Handcraft through the store end up being.

You can see the new Web Store by visiting it in Chrome. Any other browser will still show you the old design.

Dear people at Stripe,

Stripe sounds lovely and I wanted to add a voice from Europe calling for you guys to hurry up and get over here. The payment processing industry is probably a mess in the US, but I can almost guarantee you it’s even more of a mess over here if you’re not in the UK. Sounds like a great business opportunity, right?

In getting ours set up we went through a 3-month long nightmare/adventure and finally settled on Ogone+Spreedly. I’m sure you know of both. Spreedly is like Stripe in its elegance and simplicity, but it’s not full-stack, which means we’re required to suffer through the terrible UX and customer support of Ogone. Seriously, if there’s a company I could say I actually hate, it might be Ogone.

I wrote some blog posts about our experiences that I’d like to share with you in an attempt to hopefully convince you to expedite your trip across the Atlantic:

http://blog.handcraft.com/2010/09/the-payment-provider-shortlist-part-1-fastspring/
http://blog.handcraft.com/2010/10/the-payment-provider-shortlist-part-2-chargify/
http://blog.handcraft.com/2010/11/the-payment-provider-shortlist-part-3-spreedly/
http://blog.handcraft.com/2011/01/looking-back-on-the-quest-for-payments/

Please come to Europe as soon as possible. We’re over here waiting to give you our 2.9% + 30c.

Yours faithfully,

People in Europe who want to make money off their web-based software

* * *

Update: Stripe responds!

Hi Rahul,

Thanks for the letter! Believe me, we’re working on it. Expanding
outside of the US is our biggest priority. About half the team is
originally from outside the States (I’m from Ireland myself), so we
understand the pain of trying to accept money online in Europe.

So in answer to your letter: we’re not just considering it; we’re
actively working hard on making it happen.

Thanks for the support — it means a lot to us!

Best,

-Darragh

Web design is product design. Drawing a picture of the product is not designing the product. Web design is experience design. Drawing a picture of on-screen content or mechanism behaviors is not designing the experience. The functioning html/css (and sometimes JavaScript) is the design.

The key quote here is “the functioning code is the design”. All too often people view “design” as just describing something visual. But the design of a building isn’t the picture of the building, it’s the blueprint. The design of an iMac consists of more than just an illustration of the iMac, it involves all the specifications and internals. That’s design. To wall in design within the visual is to misunderstand all the skills designers must have to do their jobs well.

In the case of web design, as Andy says, the code is the design. The beautiful thing about that is that you can work on just the design, writing HTML and CSS, and suddenly you have the end result. You don’t need to go into, say, mass manufacturing. You just publish your code (and maybe clean it up a bit). This is why we made Handcraft.

But wait just a second. Has no one noticed what this argument is really about? About what the consequences are of everyone left and right wanting to call themselves a user experience designer?

That’s right. It’s becoming cool.

Let that sink in. If it’s becoming cool, then sure, you’ve got the hipster crowd who like to go about saying they were designing UX before anyone had heard of it. That’s great for those people. You know what? It’s even better for the rest of the world because now people know there is such a thing as user experience design. People like your boss. People like your clients. People with money who, before, would keep their pocketbook closed because you couldn’t convince them of the need for user-centered design or user research.

Flashback

Ten years ago a guy named Steve Krug wrote a book called “Don’t Make Me Think“. You know why he wrote that book? Well, in part he wrote it because it’s his passion and he wanted to share. But as you’ll read in the preface, there’s another reason he wrote it. He wrote it for your boss. You’re supposed to read it yourself, he says, and then pass it on to them. Because then your boss will read it on his next business trip – the book is crafted specifically to be read cover to cover on a 3 hour flight – and maybe learn something. Something about taking design and usability seriously. And something about how it doesn’t really have to cost that much if you’re pragmatic and use (advanced) common sense.

This was the challenge ten years ago, when no one gave a hoot about design. Look back at the Web back then and your job as a designer consisted mostly of trying to convince anyone to care about wanting to make things easy to use, let alone actually testing whether it was.

And then after Mr. Krug came Web 2.0 and AJAX. On the one hand these were overloaded, meaningless phrases. On the other hand they created a huge awareness for websites with more advanced functionality, opening millions of eyes to the possibilities of web applications. This was important because now you could finally start convincing your client that allowing comments to be posted before moderating them was a good thing. The onset of social media and the rise of major sites like Facebook and MySpace helped enormously by proving that letting people share stuff could actually make you a bunch of money.

The biggest stunt we could ever pull

Now, with the advent of user experience design as a hip, cool thing, you don’t have to fight so hard for that stuff anymore. People – normal people, like your boss – are slowly waking up to the idea that Twitter, Facebook, Google, and other leaders are successful because someone is paying attention to the user experience.

If anything, “user experience design” is the biggest marketing stunt the design industry has ever managed to pull off. It’s like usability and Web 2.0. It’s like AJAX and social media. You should be glad it’s here, and you should be very excited that it’s being picked up to mean “modern web design” because that means your job is only going to get easier while you get paid more.

So get over it. Let everyone call themselves a UX designer.

So what? You know what’s really going on.

More reading:

• Ryan Carson thought “UX professional” was bullshit last year
• Scott Berkun thought people should get over it because it’s about skills, not titles
• Cennydd Bowles wrote a really long post talking about all kinds of things related to being a UX designer
• Whitney Hess thinks “you’re not a UX designer if…” you don’t talk to users, and a bunch of other reasons

There are two things wrong here. The first is the idea that print designers should be designing websites. The second is that you can design a website without coding.

This is a troubling development from a company that is trusted by so many, and, in certain ways, is an industry thought leader when it comes to providing designers with tools that help them do their jobs. This is Adobe signaling they believe in tools that abstract away craftsmanship and instead rely on outdated paradigms, returning to the heyday of WYSIWYG IDEs that lull you into a state of thinking anyone can put together a successful website.

But it’s not true. Yes, print designers can learn to design websites. And print designers can be really fantastic designers. Print designers can also learn to write HTML, and do it well. Muse, however, implies neither of those things are necessary. No, it says, you just keep doing what you’re doing and this magical piece of software will handle the rest.

In the video on the Muse website, one of Muse’s product designers says ‘In five or ten years, I don’t think very many people will be coding to design websites.’ (via Elliot Jay Stocks)

How wrong you can be – it’s far more likely the opposite will happen.

Over at User Experience StackExchange, Jitendra Vyas asks the same question:

What is the difference between Wireframing and prototyping? Prototype should be interactive and Wire-frame Static? Am i right?

And Roger Attrill of ThinkUI provides a great answer:

If you are considering an application or a website, and you look at the page level for example, a wireframe and a prototype are superficially the same things, from a physical perspective. They can both be low or high fidelity, on paper or digital medium. The wireframe may be a template for many pages or a may be a unique page or screen. It is a page schematic.

Once you look at the bigger picture and how multiple screens or pages connect together, and start considering the navigation between them and the less tangible aspects of usability and interaction then you are linking wireframes (plural) together to make a prototype. The prototype is a demonstrable system.

“A demonstrable system” is a great way to explain that prototypes are something that can be experienced. Great wording here.

The prototype can still be a single page or screen, but it embodies more of a sense of engagement rather than purely of visual appearance.

Talking about “a sense of engagement” also further underlines the idea that representing an experience is a key focus of prototypes. While we argue that HTML is the best platform for this, Roger’s approach suggests that any kind of interactivity is the differentiator here. Which, I guess, can be argued. He continues by talking about the difference in mindset:

So In my opinion where it differs is the mindset with which you approach the schematics:

Are you thinking more along the lines of ‘How does it look?‘ or ‘What information and features are presented?‘ (wireframe).

Or are you thinking ‘How do I interact with this?‘ or ‘How will it be used?‘ (prototype).

Focusing on mindset in terms of what problem you’re trying to solve is a great way to outline the difference between wireframing and prototyping. If you look at tools in the market this way, it also quickly becomes clear which are great wireframing tools and which are clearly meant for prototyping.

See more answers to the question at UX StackExchange itself: What is the difference between wireframing and prototyping. Perhaps you can contribute your own answer?

Zen Coding is an editor plugin for high-speed [HTML] coding and editing. The core of this plugin is a powerful abbreviation engine which allows you to expand expressions—similar to CSS selectors—into HTML code. For example:

div#page>div.logo+ul#navigation>li*5>a

…can be expanded into:

<div id="page">
        <div class="logo"></div>
        <ul id="navigation">
                <li><a href=""></a></li>
                <li><a href=""></a></li>
                <li><a href=""></a></li>
                <li><a href=""></a></li>
                <li><a href=""></a></li>
        </ul>
</div>

In addition to this, Zen Coding adds a few keyboard shortcuts for things like selecting a tag’s inner or outer contents, increasing numeric values in a css rule or surrounding a text selection with an html tag (or better yet; a Zen Coding abbreviation).

Integrating Zen Coding into Handcraft really speeds up HTML prototyping and makes a great addition to the already syntax highlighted, context-aware code completing editing experience that Handcraft offers. To give all users a clear overview of the keyboard shortcuts available, we’ve added an overlay similar to Gmail by the simple press of “?”.

Handcraft's keyboard shortcuts

For a quick demo of Zen Coding (without Handcraft’s CSCC code completion), go to
http://zen-coding.ru/codemirror/

New to Handcraft? Sign up for free (or sign in with Google) and you’ll be trying out this fantastic editing experience in under half a minute.

• Wireframing and prototyping are two different things, even though a lot of people use them interchangeably
• HTML is a great way to do prototyping because it allows you to focus on the details
• Handcraft is a great way to do HTML prototyping because it was designed specifically for it

We also decided to create the slides in HTML using Google’s HTML5 slides library. This allowed us to prototype the presentation with Handcraft. Can’t get enough of that dogfood!

Check out our talk, HTML prototyping: because the details matter – to navigate through the slides, you can use the space bar, the directional keys, or just click on the next/previous slide.

If you came to our talk, we’d like to invite you to try out Handcraft and if you like it, we’ll give you 3 months of the paid version for free so you can dig in. Just send us an email or a tweet and we’ll hook you up.

“HTML5 Boilerplate is the professional badass’s base HTML/CSS/JS template for a fast, robust and future-proof site.” – html5boilerplate.com

Here at Handcraft we couldn’t agree more, so it’s one of the starter templates we offer for HTML prototypes. But today I stumbled upon something that struck me as odd. When I inspected the HTML source code of html5boilerplate.com I noticed it was built according to their own boilerplate template, but where it recommends using the new html5 <header> and <footer> tags they decided to go for the pre-html5 equivalents instead:  <div id="header"> and <div id="footer">.

Check out the screen I shot of webkit inspector looking at the “walk through it with me, now” section on the homepage, and its source:

I’m sure Paul Irish and his team have their reasons, and little me would be the last person on earth to question them, but I am curious to know why they chose not to follow their own recommendation and go for the native html5 tags. What do you think?

Check out the demo at http://handcraft.com/demos/cscc2

The folks over at PowerMockup have created a new set of 78 user interface elements designed specifically for the Microsoft minded.

Here’s what you get:

All design elements are based on regular PowerPoint shapes that can even be viewed and edited when PowerMockup is not installed.

• 78 fully editable user interface elements
• 84 wireframe icons
• Easy access via a separate ribbon tab
• Compatible with PowerPoint 2007 and 2010

The major advantage of using PowerPoint as a mockup tool is it’s ubiquity: almost everyone has it and knows how to use it. It provides a common design environment that bridges the gap between business users and developers.

There’s a 30 day trial, so if Windows and Powerpoint are your tools of choice, be sure to give it a try over at www.powermockup.com.

Had any experience with it? Let us know in the comments below!

If you’re a new customer

Google will ask you if you want to allow us access to your name and email address. This is just so we can identify you and set you up with an account. We’ll give you a Free account and sign you right into the editor. Once you give us access and tell Google to remember that decision, you’ll never see that screen again – each time you click the Handcraft icon, you’ll just pop straight into Handcraft itself.

If you already have a Handcraft account

Nothing changes if you already have a Handcraft account. If you signed up with a non-Google account, you can just keep signing in the old way. If you did sign up with a Google account, we support that as well. Just install Handcraft from the Web Store and allow it access to the same Google account you signed up with. We’ll put two and two together and you’ll be back in your existing account. You can also sign in with Google manually from the good old sign in screen.

If you enjoy using Handcraft, please give us a five star rating and a review on our Web Store page!

Increasingly frustrated by prototyping tools. May have to do HTML5/CSS3 self imposed boot camp after all.

May 30, 2011 14:48 via EchofonReplyRetweetFavorite

@leisa

Leisa Reichelt

Leisa’s not alone in wishing she could write better HTML & CSS so she could just do prototyping in HTML: designers who code is a growing trend that more and more UX professionals are becoming familiar with.

But learning how to code remains something you need to invest quite a bit of time into. Perhaps that’s what’s been stopping Leisa and others from becoming expert HTML prototypers.

Thankfully Leisa is also pro-active: she’s taken it upon herself to organise a UX Bootcamp program. The first session, Prototyping in Code, is intended for designers who want to pick up the basics of HTML and CSS for prototyping purposes and will be taught by Alex Morris, Anna Debenham and Peter Gasston.

It’s in London from July 22nd to the 23rd and is preceded by an introductory day for designers who’ve never written a line of HTML in their life called Code Fitness. Tickets for the 22nd & 23rd are £299 (excluding a fee) and £149 for the 21st. Sign up here.

Knowing how to code helps you produce better prototypes. The best way to communicate a design idea to your teammates and clients is through an interactive prototype. Producing your own quick prototypes brings your ideas to life sooner, releasing that inner brilliance you’re carrying around and helping everyone see what your designs are really about.

The implication here is that interactive prototypes should be written in code. So by Jared’s definition, an interactive prototype can’t be, for example, an Axure prototype, or a Keynote wireframe with click zones. It has to be code.

We agree. You should handcraft prototypes in HTML. You’ll learn more about the medium you’re designing for, be able to anticipate constraints and possibilities more ably, and become a better designer overall.

See all three reasons why learning to code makes you a better designer over at UIE.

High-fidelity prototypes can take a variety of forms: They can be coded as working HTML, CSS, and Javascript interfaces, or they can manifest themselves as non-interactive motion studies. Choose the technique that best tells your solution’s story and allows to you test any weaknesses in the system.

And there’s a great anecdote here, too:

Thumbplay, a “cloud”-based streaming music service, partnered with Method to design their next-generation app for Web-enabled televisions. Method’s designers and technologists worked together closely to create a fully animated, true-to-life prototype that allowed user testing of key service features and history states. The prototype was easily shared and demonstrated through a Web browser and, ultimately, proved instrumental in validating a number of visual and user-experience design decisions and creating a successful service.

This just goes to show how high-fidelity prototypes really allow you to get as close to the real experience of the final product as quickly as possible.

Read the full article for Jeremy’s tips on how to integrate prototyping into your development process and some awesome quotes by James Dyson and Thomas Edison.

Biolab Disaster. A game built in ImpactJS.

On his blog, Dominic Szablewski, the author of ImpactJS, writes:

These are certainly not the first games written in JavaScript to be available in the AppStore. Tools like AppMobi, PhoneGap or Titanium make it easy to bundle some HTML pages and JavaScript together in an App and display them in a UIWebView, which is basically just a browser window.

[...]

So what’s so special about these two games now? They don’t use PhoneGap or Titanium. They don’t even use a UIWebView. Instead, they bypass the iPhone’s browser altogether.

Prototyping a high-performance game in the browser is a much smoother experience than running it in a simulator or copying it over to the actual device for performance tuning. So ImpactJS’s ability to compile these games to run natively on iOS and bypass an embedded browser window opens quite a few doors in terms of the game development process.

Food for thought, right?

Now go and download Biolab Disaster and Drop for free on the App Store!

Instead of asking for 10 changes and waiting a week, you can ask for 1 change and wait 15 minutes. Evaluate the change, praise it or identify weaknesses, and suggest the next change. By asking for small changes, you take the pressure off the designer because you aren’t asking for miracles. You also take the pressure off the review process because the set of constraints and motivating concerns is smaller. The design is easier to talk about because there are a fewer factors involved.

Handcraft is great for this because every time you save your work, the live prototype is updated. Combine your prototype with live.js, and whoever’s looking at your prototype will see changes animate in real time. Working with a team or with clients this way can be a real eye-opener because not only does it help communicate your process, it helps them learn how websites are structured: what works, what doesn’t, and how elements flow together.

Try it on your next project. Sign up for a free 30 day trial of Handcraft.

Mike’s vision is one where the worlds of information architecture and user experience design blend together. That sounds familiar, considering we have a similar philosophy but approach it from a different angle, namely that of software engineering. We call our new position interaction engineering.

“Rapid prototyping means real prototyping”

A man riding a polar bear. What? I needed a picture to go with the post!

Thinking beyond the bounds of the traditional user experience designer, Mike includes elements like URL design and domain modeling as something that shapes the user’s experience. But he’s also critical of the traditional UX designer’s approach to prototyping, and that’s where his perspective comes astonishingly close to that of Handcraft’s.

His second lesson, “Rapid prototyping means real prototyping”, highlights the need for designers to be able to “prototype using the native tools of the medium: HTML, CSS and Javascript”. Entrenched tools like Axure and Flash are “inherently fake” and don’t allow people to “interact with actual content”. None of this is news to us, but it’s wonderful to hear someone from the BBC bringing up the same points.

Mike notes that HTML prototypes are more useful than those created with tools like Axure because, unlike “fake” prototypes, HTML can be reused in the final product: “[...] your prototype is actually an early version of the live site itself, so no effort gets wasted”.

He also invokes Jared Spool, who I just mentioned yesterday in The real reason the Valley wants better designers: like us, Mike agrees that designers who can write code are more efficient. But he’s also poetic: “[coding] forces designers to work with the art of the possible”, rather than letting their minds wander and expecting wireframes to be “realised by developer magic”.

Finally, “real prototyping means [...] getting on with making the damn thing”. Truer words have never been spoken.

Mike Atherton and the BBC get it and these lessons are important new goal posts in the search for a new role for designers and architects.

Below is the second lesson in its entirety. I recommend you read Mike’s entire post and look at the slides to learn as much as you can from his forward-thinking proposition.

UX dogma loves to big-up rapid, iterative prototyping; putting small, spit-and-sawdust versions of a product into play, rather than diving headlong into building the super-duper version. This is all well and good, yet the tools employed – Axure, Flash, paper mockups – are inherently fake, and therefore fail to test the most important mechanic; how people interact with actual content. Worse still, they are throwaway deliverables; expensive to create, but contributing nothing to the actual development effort required to create the live site.

Better then, to prototype using the native tools of the medium: HTML, CSS and Javascript, connected to a database of real content. This necessitates getting the data model (and thus the content strategy) in place up front, but that’s undoubtedly a good thing anyway. If information architecture is the management and structuring of information, then it must follow that this needs to be in place before worrying about how the user interface looks. Rough web pages that broadly structure and position content can be created relatively quickly, ready for iterative design embellishment. The beauty of this approach is that your protoype is actually an early version of the live site itself, so no effort gets wasted.

It’s probably heresy for many UX designers more comfortable in the Adobe suite, and who may consider HTML/CSS as client-side development that just ain’t their bag, but perhaps it’s just a skills gap that’s yet to be closed. In his IAS11 talk, Jared Spool asserted that the ‘most valuable UX person in the world‘ is one who can code. The increased efficiency in having a designer implement their own vision using native tools is clear, even if the resultant ‘code’ isn’t exactly production-ready. It also forces designers to work with the art of the possible, rather than tacitly suggesting functionality or data relationships in their wireframes that are presumably supposed to be realised by developer magic.

Real prototyping means UX can break free of its culture of interim documentation, and actually get on with making the damn thing. There’s little need for persona documents or paper prototypes when you can put real users in front of real content, real fast.

This is partially true. But there’s more to it. Silicon Valley startups are on the forefront of internet technology. The companies that want designers who can code are the ones that are developing cutting edge applications: Quora, AirBnB, Facebook, etc. These apps need to be lean, functional, and scalable. They can’t afford to design an interface that gets in its own way because the designers and developers couldn’t agree on a balance between functionality and good looks. What’s the best way to make that happen? Have the designer and developer be the same person.

The new design constraint is being able to code

When a designer can code, she makes decisions based on an understanding of design and of the result that design is going to create. If that design is too complicated, as a coder, she knows it’s going to make her life harder: getting it to work in all browsers (including IE7), scaling to mobile with techniques like responsive design, being able to quickly iterate when design elements don’t meet functional requirements or usability test results, etc. Her design is going to be easier to implement and lead to better results by virtue of her knowledge in this area.

On the other hand, designers who can’t code aren’t constrained by that wisdom. And that’s a weakness, not a strength. Sure, if you’re designing an amazing-looking promotion or pamphlet, you might want to focus more on the bling and less on the quality of interaction. But for an app – Silicon Valley startups are putting out web apps and mobile apps faster than we can blink – the number one metric of success is whether it works well. Pure designers won’t be able to do that as well as hybrids who can also code.

“Whoa”

Is Neo a designer who can code?

Designers who can code are like Neo in the Matrix: they can see through the world around them (the app) into the underlying code operating beyond everyone’s vision. That affords them a greater understanding of their environment, allowing them to successfully bend the rules where necessary and possible. But they know their limits, and they know when to depend more on their coding or design abilities when required.

Designers who can code are the future

The reason Silicon Valley startups want designers who can code isn’t just because it’s easier and cheaper. It’s because they know where things are headed. They’re building the next wave of great apps and discovering a more efficient way of doing so. The established companies aren’t – they’re called established companies for a reason. And they need to step up if they don’t want to get left behind when designers who can code  become the norm.

There’s a reason leading designers like Rebekah Cox, Glen Murphy, Wilson Miner, and Ryan Singer all said designers should be able to build what they design. It’s not because they’re cheap. It’s because they’re the best.

Jared calls designers who can code “super designers” (and in a previous talk, referred to them as “the Holy Grail” and “unicorns”). Perhaps today we can refer to ourselves that way. But in a few years, being able to write code will be required for any web or mobile app designer worth her salt.

We built Handcraft for designers who can code. It’s the best way to create real HTML prototypes not by dragging widgets around, but by writing the code yourself. Check it out if you’re one of Jared’s fabled super designers – we use it ourselves every day.

You like to do your mockups in markup. CSS and Javascript are the tools your reach for, even before you hit Photoshop or Illustrator. You believe nothing conveys a design concept like a functional flow, and you love iterating quickly over designs and seeing things go live. You’re a developer and a designer.

Job openings like this make me really happy because they reflect a growing understanding in the user experience and interaction design community that designing in the browser is a fundamental skill designers should have. Definitely a company to keep an eye out for.