Adobe’s new Muse is a product aimed at helping print designers design websites without coding.
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.
Last year we wrote about how wireframing and prototyping aren’t the same thing. A few weeks ago, I gave a talk at UX Brighton about the difference as well. We decided it basically comes down to this: wireframing is about communicating structure early on, prototyping is about the user experience. Continue reading →
If you’re not familiar with Zen Coding, here’s a brief description taken from its homepage:
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>
This week we headed to Brighton in England to give a talk at a UX Brighton event about “Practical Prototyping”. Our talk focused on a couple of topics we’ve talked about on this blog over the past year:
- 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
<footer> tags they decided to go for the pre-html5 equivalents instead:
<div id="header"> and
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?
Since we created our code completion addon for CodeMirror (see this post), it’s been adopted by several other projects, both open source and commercial. Thanks to the people at webpop we’ve been able to take CSCC further and bring context awareness to the table.
Check out the demo at http://handcraft.com/demos/cscc2
Apple Keynote and Microsoft Powerpoint are designed for creating presentations. But their drag & drop nature has led some people to find another excellent use for them: wireframing. By dragging UI elements onto a canvas in these tools, you can quickly mock up the visual flow of an app or site in either low or high fidelity if you have the right set of UI element templates.
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!
Handcraft is now available in the Chrome Web Store. This means that if you use Google Chrome, you can install Handcraft and it will appear in your new tab screen. Clicking it there will take you straight into the app using Google single sign-on.
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!
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.
UIE’s Jared Spool posted a follow-up to his “Why the Valley wants designers who can code” post, which we wrote about last week. His new article, which he says will be the last from him on the topic for a while, covers 3 reasons why designers should learn how to code. His second focuses on prototyping:
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.