Category → Design in the Browser
“A designer who does not write markup and css is not designing for the web, but drawing pictures.”
Andy Rutledge wrote a blog post saying that web design is product design:
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.
Common Sense Code Completion is now context aware
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
- Common Sense Code Completion, now context aware.
The real reason the Valley wants designers who can code: they’re better
Jared Spool over at UIE just published an article about “why the Valley wants designers who can code“. In it, he asserts that startups in Silicon Valley want to keep teams small and therefore look to combine critical roles within a single person, while established players in the industry can afford to spread those roles out over more people.
Singly’s job opening for UX designer: “You like to do your mockups in markup”
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.
Listen to the ‘i’ in Team
When a development team is made up of different specialities, one or more members are usually responsible for writing top notch quality HTML and CSS. Even though the common goal of the team is to build a kick-ass app or website, the individuals making up the team don’t always have the same path or means to get there. And as there is in fact an ‘i’ in Team, here’s our real life example of why you should listen to this individual and use the right tool for the job.
There is an 'i' in Team. Courtesy of Jaco Haasbroek.
Backfire – Save CSS changes made in Firebug
Firebug offers a great way of doing on-the-fly CSS modifications right there where it matters: in the browser. It allows you to actually “design in the browser” which is part of the Quplo philosophy. The only problem is that CSS changes done in Firebug aren’t persistent, so you have to redo them in your editing environment in order to save your work.
Well, not anymore. Here’s Backfire: the save button for Firebug.
Backfire fires your CSS changes back to the server.
Create a prototype with the HTML5 boilerplate
Heard of the HTML5 boilerplate? It’s a recent great idea by Paul Irish and Divya Manian. The basic concept is that it gives you a great head start to creating a new HTML5 website by offering a pre-filled HTML file, the right CSS setup (including taking handheld styles into account), and automatic compatibility with older browsers. That’s great for people learning HTML5, but also for more experienced people who don’t want to keep typing out the same old boilerplate code (hence the name).
When we saw this, we immediately knew it would be great for quplo, since quplo is also all about getting somewhere faster and DRY. In our case, it’s about building prototypes superfast so you can communicate about them more easily and reach the end goal – whatever that may be – faster.
So we downloaded the HTML5 boilerplate and created a prototype template with it.
How the browser roundhouse-kicked Chuck Norris
It struck me this week. Browsers nowadays are so kick-ass that they outdo Chuck Norris’s badassness. The current momentum of skyrocketing browsergoodness can’t even be surpassed by Holland winning the worldcup next Sunday. Or perhaps it can, but let’s have a look anyway at where browsers are today shall we? Pure for the the sake of the great joyride that we’re in for when going retro.
Chuck Norris showing off his badassness.
Why we’re not building yet another visual prototyping tool
In our last few posts, we talked about our philosophy, designing in the browser, and how we think the modern IDE sucks. These two ideas might seem unrelated, but in fact they’re essential to what we’re trying to do with Quplo: build a workspace that makes it easy to create interactive prototypes by writing code. Continue reading →
The modern IDE sucks
Here’s a screenshot of a modern IDE, the Eric Python IDE:
This screenshot is a great example of what’s wrong with IDEs today (here’s one of Eclipse or one of Visual Studio for comparison). Although it’s an extreme example, all the windows, buttons, icons, selections, lines of differently coloured text and other distractions hardly craft a focused workspace. In fact, what are integrated development environments even designed to do?
“IDEs are designed to maximize programmer productivity by providing tightly-knit components with similar user interfaces”
– Wikipedia’s article on IDEs
Yet, according to Wikipedia, “because an IDE is by its very nature a complicated piece of software, this high productivity only occurs after a lengthy learning process.” For the purpose of creating web-based prototypes, we think things can be different – simpler, more intuitive, and more integrated.
The same Wikipedia article mentions that an IDE “provides many features for authoring, modifying, [and] deploying software” and “increases developer productivity”. That sounds a lot like what a tool used to develop interactive prototypes should do.
The modern IDE sucks. We think designing in the browser allows you to get away from overly complicated IDEs with huge learning curves and arrive in a friendlier environment where productivity and ease of use are paramount. We’re working on a user interface for Quplo based around these ideas. Stay tuned.
In our follow-up post, How we redesigned our editor, we talk about exactly what kind of changes we want to bring to the IDE.
