I think there’s a difference between skipping a phase versus internalizing a phase. As young students, we go through a very formal writing process in order to learn the skills needed to be a good writer; I doubt very seriously that any of us go through that same, explicit process as mature writers. We’ve internalized those things we were taught.

At Q42 and on the Handcraft team we frequently do sketches and then immediately move on  to interactive prototypes. Not because we want to skip wireframes, but because that part of the process is kind of redundant. It doesn’t add anything of value when you can just get on with the things you really want to communicate to your client, namely the refined details of the interactivity you’re mocking up.

Stephen comments on communication as an important stage in the process, too:

Asking someone to comment just on the interaction or just on the structure–independent of the other pieces — is a bit like asking someone to judge a chocolate chip cookie based on only a handful of ingredients. “Here, these are the wet ingredients (eggs, sugars, vanilla)–what do you think of this cookie?” How can we possibly expect to get good feedback on such an incomplete experience?

Fully interactive prototypes allow the client or stakeholder to comment on the actual experience rather than a picture of it. That way you get a constructive discussion going early on about the final product instead of wandering around in idea land for too long. Getting to this stage as fast as possible means you can spend more time testing with real people, which is another point Stephen makes:

I’d argue for an integrated, holistic approach to UX that serves up as complete an experience as possible, as early on in the process as possible. I’m talking days, maybe even hours in some cases. This is not so we can be done more quickly, but so that we can use this new found time to iterate more frequently with actual users, leading to better, more user focused experiences.

We talked about this in our presentation at UX Brighton last summer: focus on the details rather than skipping over them just because you want to be done sooner.

Stephen’s a great thinker and writer and it’s awesome to see a gradual move towards this kind of thinking in the design industry overall. Read all of Stephen’s thoughts on the subject at The Pastry Box Project: Wednesdasy, 4 April. Here’s hoping he works this angle into a future talk!

If you were affected by this downtime we’re truly sorry. Please send me an email at rahul@handcraft.com if you ran into any trouble and we’ll work something out.

The cause of the problem

Late last night we discovered that handcraft.it was not responding. After looking around we determined that it was because the handcraft.it domain name appeared to have expired. This sounded very strange because it had been set up to auto-renew. Unfortunately, it was already past business hours in the Netherlands when we discovered the problem and our hosting provider was unavailable for support. As a result, Handcraft was unavailable overnight in Europe.

Early this morning we immediately contacted our hosting company and let them know about the problem. It turned out that the domain name had expired due to a combination of unlikely events that happened last year when we originally registered the domain name. A payment error combined with administrative errors from two different hosting companies led to us believe the domain name was registered correctly when it was in fact set to expire. Our hosting provider had also contacted us to let us know the domain would be expiring, but their emails were filed as spam in our inboxes and we didn’t see them until it was too late.

What we’re doing to prevent this from happening again

We’ve now recovered the domain name and will be moving it to a hosting provider that provides better support and with whom we have a longer relationship. We’ll also be (doubly) confirming that all of Handcraft’s domain names are functioning completely and set to renew correctly.

Again, we’re incredibly sorry this happened and we’re doing everything we can to prevent it from happening again.

We use Handcraft every day. It’s incredibly important to us that it be available 24/7 and we understand if that’s the case for you as well. Again, you can reach me at rahul@handcraft.com if you want to discuss any problems you’ve faced during our downtime.

Thanks for using Handcraft.

Using Handcraft has been an interesting experience. Building a web site directly in a browser is something I never thought I’d be doing, though looking back now it doesn’t make any sense not to. I regularly use web apps to write posts for Appstorm, whether it’s on Appstorm itself powered by WordPress or using Google docs, so I might as well use a web app to create my own sites or write up web code anyhow! If you’re looking for a text-driven website designer for the web, give Handcraft a try. You might find yourself addicted to your new favorite online text and web editor!

Darren even noticed that we built the Handcraft website with Handcraft:

Both the site and editor have an intuitive functional design, which looks awesome! And while building sites on a website is a funny concept to get your head around, this next interesting fact will make that all the harder – the Handcraft website is built in Handcraft itself as a prototype! It’s great to know the developers themselves use this app themselves, never mind using it to build their website!

Much appreciated!

If you work in a field that requires collaboration for success, then Handcraft could be a tool worth checking out. After you start a 30-day trial, Handcraft will guide you through all the steps to create your first HTML prototype. Give your first prototype a name, select the URL where it will be located, and then get to work perfecting it using the Handcraft editor. Handcraft’s editor was designed in a way that lets you skip repetitive work across multiple pages and automatically completes commonly used HTML and CSS codes. The editor also includes an error-handling tool, which scours your prototype to help you figure out what’s not working correctly. Copywriters, meanwhile, will appreciate being able to write their text directly into the HTML code, rather than emailing back-and-forth with developers.

That’s great! Thanks Stephanie and Appvita!

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 15: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!