Category → The Status Quo
An open letter to Stripe
Update: Stripe responded below, and if you want Stripe in Europe you can leave your name and country here
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
Don’t stop calling yourself a UX designer – it’s working!
It seems like there’s a neverending debate over whether people should be allowed to call themselves “user experience designer”. On one side of the fence you’ve got people assigning themselves the title because they feel that it represents best what they do, or have done for years. On the other there’s a crowd calling the former group names because they don’t feel they “deserve” to call themselves something they appear not to be.
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. Continue reading →
Adobe doesn’t get it
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.
Knowing how to code helps you write better prototypes
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.
How the BBC feels about rapid prototyping
In 5 Lessons from Beyond the Polar Bear, BBC information architect Mike Atherton lays out how domain-driven design has changed his and the BBC’s perspective on designing the user experience. Many of his points represent the shift towards designing the holistic experience that web designers are going through at the moment, and late in the article he even goes so far as referring to them as “information experience design architects”. Continue reading →
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.
Why interactive prototyping and Balsamiq Mockups can live together in peace
Balsamiq Mockups’ new manifesto includes a chapter about prototyping. Here’s an excerpt:
Wireframing + real running code is way better than prototyping
We consciously decided not to let our users specify interactivity other than the ability to link wireframes together into a storyboard.
Two reasons:
- We’re not huge fans of building large prototypes.
- Letting you specify behaviours and click-actions would inevitably turn Mockups into a much more complex tool
Geez, Peldi! We’re hurt! 
Write less CSS with Less CSS
Less CSS really does what its title claims. It’s an elegant approach that adds all the syntactic sugar you ever wanted to vanilla CSS, such as variables, nested rules and declaration templates. And it starts out by being 100% compatible with your original CSS files. So what are you waiting for? The only way is up.
Less CSS.
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.
Improving the website production process – Part 1: Exporting to development platforms
If you’re involved in the website production process, chances are your job involves wireframing, visual design, prototyping, development or a combination thereof. More often than not, the process involves designers tossing designs “over the fence” to a development team. Regardless of what side of the fence you’re on, it’s clear that there’s room for improvement.
The website production process.
