Macaw is just what I wanted

I get inspired when I can visually tinker with experience design. This is the reason that Macaw.co got my attenion and I adopted it almost immediately. I finally found a product that allows me to do that, from Macaw.co, a recently launched rapid web UI prototyping tool. It’s got its warts, being brand new, but I like it and I expect it to do well.

I get inspired when I can visually tinker with experience design. This is the reason that Macaw.co got my attenion and I adopted it almost immediately.

Macaw user interface
blank canvas in Macaw

I hailed Twitter Bootstrap when it was launched. It helped me and many others  with UI prototype work. Some seemed to prefer deploying Bootstrap default experience with little change. I don’t like that much. I would often customise the look & feel to make it a bit proprietary. Over time I came to realise that I didn’t particularly enjoy tweaking and tuning the myriad features exposed through the LESS assets. There is nothing wrong or limited with Bootstrap per se. Web browser development tools are also a good help for quickly trying out UI ideas. There are many online sites such as codepen that help you experiment with snippets and small features. These are all fine but, I just wasn’t getting inspired by any of it. What these tools lacked – that would get me excited – was the ability to just draw my idea of an entire page as I envision it, tinker only with the drawing, and then immediately get the code behind without resorting to any extra artifices. There is an emerging bunch of tools that allow you do that in a cost effective manner.

I discovered that my way of tinkering with web design worked better if I could do it visually. As I examine visual elements I get more ideas and I can iterate quicker. Going back and forth to the LESS source files and tuning design was too slow to entice me. I am not a designer by education so I make lots and lots of tweaking before I like something. As a kid I used to love drawing things. I would typically start by drawing a line or some randomly curved shape, then as I added to that some kind of shape would start to emerge and I would finalise my drawing that way. If I ended up drawing a horse or a house that was usually not even in my mind when I started. That was my way of playing with pen and pencil. It seems that is also how I can enjoy doing UI work.

For a long time I relied on Omnigraffle, not really a web design tool, and Pixelmator, also not a real UI web design tool. I’ve used Adobe FireWorks on and off for years. FireWorks is a nice tool but it never got me excited much. It seemed that I couldn’t find any product out there that I would want to stick to. That changed recently.

There’s a new product that allows you to visually design what you want, then get a baseline html and css code that embodies that. It’s called Macaw. I saw a brief video announcing its features and immediately decided to buy a license when it shipped. I got a copy at the beginning of this month, started using it, and it felt right away that this was how I always wanted to work with web design.

Aside from the immediate feedback, one benefit I particularly appreciate with Macaw is that the authoring assistants are intuitive and help you just the right way. As a non-negligeable bonus it generates a minimal base code that can be directly fed into an application design. Here are two radically different design I made with it.

macaw - design prototyping example
macaw – design prototyping example
Web UI Prototyping with Macaw
Web UI Prototyping with Macaw

I create these artefacts just like I would in Omnigraffle, however the whole experience of manipulating the elements fits perfectly with the job: desiging a web front-end. Once done, the code that Macaw generates is clean and minimal, it does link to jQuery though. So, I could just take the code I get from this and embed it in the application code. This approach is more to the point, and more efficient than say using a free html template downloaded from the web.

macaw generated css
macaw generated css
macaw generated source files
macaw generated source files

Before Macaw I tried several products of which many are online solutions. I won’t list them since this isn’t really a posting on product comparison. While lots of nice experiences are available I was often disappointed with the code that got generated. The problem I expect to solve with these tools is to get started with a clean slate and be able to repurpose code with minimal effort. This means that I didn’t want any dependencies in the code and that seemed almost impossible to achieve. For this reason I couldn’t settle for anything in particular and kept on to a traditional model where the UI design assets were fairly remote from the code produced to implement it. I don’t need to do that anymore, I can rely on Macaw to visually tinker with prototype designs.

Of course when it comes to serious web crafting like making animations or complex interactions Macaw wouldn’t fit the bill. Webflow for example seems to be another nice one, particularly suited to animation rich UIs. The produced code embeds relatively proprietary JavaScript code. And the business model seemed to be favourable to repeat uses or even hosted solutions. For my particular needs I saw these as compromises I didn’t really want. And honestly I would just hire a professional designer if the experience is complex or that it needs to be very sophisticated. I am an IS&T architect who believe in all-round craftsmanship. I want to deliver the whole solution. If it needs to look spiffy and flashy then I call out to professional designers.

Having used the product for a little while now, I am convinced that Macaw is the tool that I was missing so far. I can now deliver complete end-to-end experiences to clients with the tools that I am comfortable with.

An intelligent take on the non-sense ranting about Skeuomorphism

Joel Hladecek says, “Essentially, every user interface on Earth is ornamentally referencing and representing other unrelated materials, interfaces and elements. The only questions are: what’s it representing, and by how much?”

This is a thoughtful article, the first one I have read since somebody somehow sparked a non-sensical debate going on in recent months. The author says eloquently what I’ve been thinking, my favourite excerpt is this:

Essentially, every user interface on Earth is ornamentally referencing and representing other unrelated materials, interfaces and elements.  The only questions are: what’s it representing, and by how much?

Read up the whole article here: Why Apple’s Interfaces Will Be Skeuomorphic Forever, And Why Yours Will Be Too

The Safari Reader button is a little unassuming gem

Apple initially introduced this feature with OSX Lion. When I saw it I immediately tried it then just as quickly forgot about it. The feature is still there on OSX Mountain Lion, and I only recently realised that I have actually been using it all the time without having noticed the point in time when I changed habits.

Your Mac, just like your Windows machine I guess, is full of nice features that you seldom use. If they were truly metering the usage of all the features that get thrown on new OS releases, I think it would be astonishing to see how much bloat creeps around unused.

Safari Reader isn’t such a bloated stuff, it comes in really handy for folks who frequently read articles on the web. Look at the two pictures attached below, it is immediately obvious which one you would prefer to see, that’s how useful the Reader button is. It is not available on all sites as I’ve experienced it, I didn’t try to find out why, but if you are aware of it, it can nicely enhance your reading experience without a sweat. That’s why I use it all the time.

Normal view of an article on Safari, before pressing the Reader Button
Normal view of an article on Safari, before pressing the Reader Button

 

After pressing Reader button
The same article on Safari, after pressing the Reader button

Conservative innovation as a path to better user experience. Avoid Feature Debt.

Designing sustainable user interface is a very hard task that could take a large number of retries. The wider an established user group is, the more conservative user interface design changes should be. If a complete user interface overhaul is required it may work out much better to present an entirely new product to users. Doing that sets an expectation of a new experience, this gives an adequate cognitive comfort to users.

Designing sustainable user interface (UI) is a very hard task that could take a large number of retries to get right. A technology powered solution that spares its users tedious learning will fare better than those who simply skim over such issues in favour of other agendas. Realising this makes me respect even more people who invented some of our everyday tools such as drinking glass, the pen and paper, and so on. This post is about highlighting some aspects of UI design decisions and why that is where conservatism should be preferred.

I always push hard to find out every detail I could about the problem domain that I am dealing with, preferring to postpone technology concerns until I know enough about everything else. Incidentally, this way of working tend to ruffle the feathers of those who prefer to skim over details, the manager looking for quick way out and avoiding any potential blame. I digress there a bit. In essence, looking to get more than one perspective of a problem domain makes me spend hours exploring wide ranging concepts, business and technical blueprints, various vendor solutions, looking to debunk blind-spots from the endeavour. Ultimately I found out that UI design decisions where happening everywhere even though people weren’t looking at things that way. In this post I’d like to highlight some of the learning points on user interface issues:

  • A stable UI design will sustain several product revisions without requiring that users learn and adopt new behaviours. Designing and rolling out a stable user interface seems to be an extremely difficult task, partially because the UI scope is often hamstrung by blind-spots.
  • Technology vendors that tend to frequently overhaul their UIs will upset users, cause people to scramble to adapt, disrupt well honed user productivity work flows, distract people from doing their real job.
  • In software development texts you often read about “Technical Debt”, meaning that some corners were cut for technical reasons with the intention to make amend at some (often unspecified) time in the future. In a similar vein I also frequently noticed what I would call “Feature Debt”, which has a broader meaning than its technical counterpart and is mostly about adding clutter. I’ve not heard of this term before, so I am creating it to make my point. An example of Feature Debt is when people sneak in requirements that only reflect their own personal preferences far removed from the actual problems at hand. Another example of Feature Debt is when designers don’t envision the user’s daily activities while designing a solution. Feature Debts stemming from a technical way of thinking tend to result in cognitive tax on the UI experience. I will write a dedicated post on Feature Debt when I get a chance. The point here is that Feature Debt is really hard to fight, it goes against conservative UI innovation and coud cost dearly.

Changing the UI of a well established technology should not be taken lightly, because of the unnecessary upset it might cause. A symptom of Feature Debt is when a solution is deployed then outsiders react in bewilderment, wondering how such product release came to be. Another sign of this is when folks have to scramble to learn new habits for things that are otherwise plain and simple normal activities.

With this way of thinking in mind, I try to analyse new technology product releases that hit the market, sometimes you expect to see revolutionary new interfaces and may be disappointed not to find that. Sometimes new products receive negative media or user reactions, you wonder how that could happen when the organisations behind them clearly had all the resources they needed to get things right. It is always too easy to shout at bad decision making with hindsight, especially from an armchair executive perspective, but it is very difficult to spot issues as they are happening. People often seek prescriptions as an easy way out, some of shortcoming of such prescriptions is that  they make our minds lazy and could be giving us an excuse to blame someone else if things don’t work out. To illustrate the effect of the mind laziness, imagine a situation where someone could perform a mental mathematic calculation but they stop trying if a calculator is at hand, over time they lose the ability to perform any mental calculation at all. That is also what happens if we keep looking for prescriptions and stop thinking things through by ourselves.

One thing that could help in IT driven initiatives is to look out for Feature Debt, they typically won’t survive proper user testing, won’t make it through the “five whys”. Feature Debt has a snowball effect, everything that trickles down from it will amplify its negative impact. When a group or organisation is caught in Feature Debt, very smart people might totally overlook obvious faults simply because they would imagine that fellow smart people must have vetted things and nobody wants to look bad or sound like they are obstructing. Such invisible pressure would nurture Feature Debt, people would start rationalising them and after a while feature debts become indistinguishable from real user wants, that’s when the damage potential is maximal.

Conservative Innovation is about looking for those precious UI experiences that must be preserved as one innovate, actively looking for Feature Debt and removing them from the picture before they grow and become ingrained. The conservative part is really about avoiding changes in what is already working well. When considered this way, examples can be found in a lot of successful products out there. This is also what drives copy-cats because they don’t risk trying something new, they try to follow what appears to be working and accepted by communities.

This post isn’t asking to avoid change, that wouldn’t make sense. But rather, this is about ensuring that user comfort is sought and protected very early on and often as you go about innovating.