Wireframes, Mockups, Prototypes – FlairBuilder

Hi there,

This week start brings a long awaited fix for FlairBuilder. Quite a few people have reported that copy/paste was not properly working on Mac OS X. This weekend I finally was able to track it down and fix it. I am so embarrassed for it taking so long but it’s finally fix and that’s for good!

Besides that, I also fixed some other issues that were happening if you would edit FlairBuilder project files by hand in a text editor. It was also a platform dependent issue, but most of you should not be aware of the issue of the fix.

In the end, in preview mode, double click on the icon component still triggered the icon gallery to pop-up. I quickly fixed this, too.

This is indeed a small and quick bug fix release, but I’m sure it will make few of you very happy. At least I am very happy and excited of finally taking that copy/paste issue off my mind.

In following couple of weeks I would like to focus more on the website and on creating some explanatory videos. Nevertheless, if you encounter any issues or if you feel like something it’s a must have addition, just let me know and I’ll see what I can do.

Thanks so much everyone for helping me getting each release out, finding bugs and, overall, make FlairBuilder a better product!

Unknown, here I come!

In an ideal world, each big subject from the software development process would be handed to a specialized professional: UI designers, programmers, architects, database administrators etc. Unfortunately, this is not the case most of times. There a plenty of cases out there where projects suffer from lack of proper expertise and well trained people. That’s not to say we should know everything, nor that we should refuse doing work we are not sufficiently prepared for. From freelancers to big companies, we are sometime facing the need of wearing someone else’s hat. In those cases we have no other option but to simply get ourselves wet and just do it.

While the Internet is big place, stuffed with lots of information and answers, it doesn’t hurt ones knowledge base to play, from time to time, with subjects collateral to your main professional field. Besides enriching your skills, it also gets you a little bit more prepared when forced to actually use that knowledge.

And while we should always respect our more experienced colleagues and be aware of our limits, I personally find no shame in being an amateur in a particular subject.

amateur: “one who has a taste for (something),” from Fr. amateur ” lover of,” from O.Fr., from L. amatorem (nom. amator) “lover,” from amatus, pp. of amare “to love”. Meaning “dabbler” (as opposed to professional) is from 1786.

These being said, I’d like to summarize in the following some of my findings regarding UI design, listing the big items that a developer should at least be aware of when programming user interfaces.

1.  Content Layout

This is of course very important. A nice, aesthetic and well balanced content layout will assure that users will easily spot what they are looking for. A technique which was well known and used in print media for a very long time, and has got a lot of attention in the past few years is the so called grid based design. Basically, it means that you will organize the content of each screen such that it will fit nicely in a grid of equally sized vertical columns.

• Designing With Grid-Based Approach
• 960 Grid System

2. Typography

Readability is another key factor in the way users interact with your software. Understanding basic principles of typography such as font types, sizes and families will help you improve certain aspects of the user work flow. And sometimes very sensitive aspects, such as check-out or sign-in process.

• Typography is the backbone of good web design
• On Web Typography
• I Love Typography

3. Colors

While written words send a clear and explicit message, non-verbal communication can also be used successfully to help users fulfill their tasks or enjoy using the software. From establishing a certain mood to sending specific messages (warning or error messages for instance), colors are an important factor in achieving the desired result.

• Color Theory for Digital Displays: A Quick Reference (Part I and Part II)
• Techniques & Tools for Using Color In Computer Interface Design

4. Technical writing

Every bit of text used in your software user interface it’s you talking to the users. Sometimes users can guess things based on their previous experience with other software applications but, more important, the rest of the time they don’t. A self conservation instinct makes us ignore what we don’t understand. But when confusion or misunderstanding prevents us from achieving a goal or finishing a task, that will lead to pain and frustration. I have personally seen successful software applications with both very terse as well very long and explicit texts. But they both had very good reasons to do so. Decide for yourself but be very cautious on every piece of text you put in the UI. Make sure it gets read as intended on the other side of the screen.

• Technical writing and Copywriting
• Copywriting is Interface Design

5. Error handling

This may be considered a sub-item of the previous point. Nevertheless, it is so important that it can be very well taken by itself. Error messages are extremely important. One can not stress enough how much time is actually spent on a feature after that feature has been completed. From properly documenting it for the user and all the way up/down to the customer support department, a mis-implemented feature will cause lots of problems and will cost lots of money. Make sure you do everything you can to anticipate anything that could go wrong (because it will go wrong eventually) and try to take control when something bad happens.

• 10 Tips on Writing Hero-worthy Error Messages
• Error Message Guidelines

6. Forms

I guess that there are very few software applications that don’t require, at least once, some sort of input from the users. In the end, that’s why we call them user interfaces, because they represent the mean by which the computer exchanges information with a human being. This means that data flows in both ways, from the computer to the user and the other way around. Forms grew up to be a quite complex subject, too. From simple login or sign-up forms, up to very complicated forms like flight bookings or even more complex ones, UX professionals have tried to come up with the simplest and most efficient ways to improve forms design and usability.
There are several aspects that should be taken into account when designing and implementing a form, such as: label/controls positioning, input validation, double-submission prevention, invalid data submission prevention, error and warning messages, default values, hints and help messages etc.

• Web Application Form Design
• Web App Form Design a talk by Ryan Singer, designer at 37Signals
• Defensive Design for the Web: How to improve error messages, help, forms, and other crisis points

7. Keep it light and simple

As tempting as it may be to stuff everything into the main screen or on the home page, up high above the fold, well… as dangerous that is. Cluttered and bloated interfaces are as ugly and hard to use as the cluttered and bloated code that we all have to debug from time to time.
Users will have a hard time making their way though dozens of UI elements that each will ask its own right of being clicked or accessed. As a matter of fact, most of the time users will only access a very small percentage of the features initially thought to be needed. Learn what are those features and differentiate them.

And even if there are plenty of things that you need to show your users or to ask from them, you don’t need to do that in one step, do you? Take it step by step and lead users to the end of each task gracefully and gently. They will thank you for that or, at least, you will save them time and frustration.

• Progressive Disclosure

8. Understand your users

This may also be translated as: think like an user, use the application yourself daily, understand the problem your software is solving etc.
However you may put it, it’s challenging and a quite difficult thing to do. I have tried to address this aspect in a previous post. Usually there are business analysts or product managers that are supposed to do this job for the developers. In an ideal world, a nicely crafted set of requirements documents would be handed to developers and a beautiful software will result, perfectly matching client’s vision and needs. As you may very well know, this doesn’t happen. At least not always.

It’s then up to all of those involved in the software development process to do their best in making sure the delivered software will prove to be useful and will really solve people problems.

What are your thoughts?

I am not an UI designer, nor or UX professional. So what I have wrote above may very well be incomplete or wrong. I’d love to hear your opinion, thoughts or whatever you may find useful to be mentioned.

Thanks for reading this!

Update:
A great article aimed to future UX designers was published by Whitney Hess: So you wanna be a user experience designer — Step 2: Guiding Principles. It also contains a great list of resources and will go deeper into the UI design field.

Another great talk given by Ryan Singer is UI Fundamentals for Programmers. I’ll embed it here for your convenience.

Hi there,

It’s been two weeks already from latest release. Although last week I haven’t made a release, due to my trip to European Software Conference in Berlin, this week we have some very, and I really mean very exciting updates.

Something that has been announced previously in the “Coming soon…” section of the features page, well, that is now available as a beta version of the feature. Which is…

Import from Balsamiq Mockups

Starting this version you are now able to import a set of mockups created with the excellent Balsamiq Mockups and group them into a new FlairBuilder project. Now there are several exciting things about this, which I’ll try to point out briefly:

Multi page prototypes

Balsamiq Mockups can be grouped into a single folder, for instance, and linked together through links attached to certain elements. FlairBuilder will make this grouping more apparent with its explicit support for projects and page grouping in folder and sub-folders, right into the application interface.

Master pages

A great way to reduce duplication between pages is by using so called masters, pages that are used as background to other pages that have elements in common. FlairBuilder offers you a very flexible support for masters as you are able to define an indefinite level of masters for your prototype pages.

Interactions

While Mockups interactions are reduced to page-to-page navigation (which is great, given the intentional simplicity of the tool), FlairBuilder goes one step further into prototyping by offering a set of fully interactive components and widgets. All those static components from Balsamiq Mockups will now turn into real, interactive components. Besides that, where it makes sense, FlairBuilder will also import links between pages. The most basic examples are buttons, links, button bars and link bars.

More than mouse clicks, FlairBuilder also supports events as double click, mouse hover/enter or mouse out, focus on/out and even keyboard events. There is a wide range of possible things that you can prototype using these events. Plus, FlairBuilder comes with an extended set of actions such as opening/closing pop-ups, displaying floating panes (or drop-downs, as you may also call them), browse through tabs or view/card stacks etc.  If you’re coming from Balsamiq Mockups world, you should definitely take a look and give it a try.

Conditional Behavior

Once you imported your mockups into FlairBuilder, there are extra things that you can do for a better experience. One the these things is defining conditional behaviors. You can restrict an action to be performed only if a set of conditions are satisfied. Certain components can be named and their properties will be used in building such conditions. I tried to make the process as intuitive as possible so defining conditions should be easy enough.

Beta limitations

Yes, this feature is still in beta stage. There are few limitations, some inherent to the difference between Mockups and FlairBuilder, others that will be removed soon.

While most of Mockups widgets have been matched against the set of widgets offered by FlairBuilder, there were also some that didn’t make sense to be imported. I skipped components as Red X, accolade or Scratch-Out, as well as iPhone components, for instance.

Images will be imported as image component but not yet the source of that image. All you have to do is double click the image place-holder and browse for the image, which usually resides in the same folder as the imported files.

I still have to match the set of icons supported by Balsamiq Mockups against that from FlairBuilder. Also Balsamiq Mockups supports multiple sizes of images and that’s something that I got to add to FlairBuilder, too. These are things that I intend to finish in the upcoming weekly releases, so hang on!

I am so excited about this new integration feature. It’s something that I had on the pipe-line for quite sometime and I finally found the time to get it out to you guys. So feedback is most wanted, needed and welcome.

I absolutely need to thank Peldi of Balsamiq for his openness and for sharing the BMML file format with everyone. This integration would not have been possible without his awesome way of doing business. Being open is the way to go!

I also need to thank Enrico, the creator of Napkee, the other tool that lets you turn Balsamiq Mockups into interactive Flex or HTML prototypes. He helped me along the way in developing this feature. He actually shared a code snippet with me. Isn’t it just awesome?

New Components: Triangle and Ellipse Shapes

Following a ping from Caroline, I added two more shapes to the set of widgets in FlairBuilder: Triangle and Ellipse. These two shapes, together with the existing rectangle shape, should give you more options in mocking up components that are not supported by FlairBuilder. I also made these shapes interactive, so you can attach events to them (mouse click and double-click, hover and mouse out). Enjoy!

Tootips for (almost) every one!

Thanks to Andrey‘s request, I changed a bit the properties panel and now I let you add tooltip to more components. Actually most of the components now support tooltips. If there’s still something you’d like to ‘tooltip’, just let me know.

Back and Home Buttons in the Viewer

One of the most awesome things that happen in a microISV is when a client comes to you and says: “Man, your tool is great but here’s a pain I have…”. Even better is when you are able to easily solve that painful problem (especially if it’s a pain created by your tool :p ). Anyways, here’s a recent request from Karl Gilis:

“Add Home and Back button to free viewer. This would make Flairbuilder not only the ideal tool for creating mock-ups / wireframes, but also make it very usable to do real user testing.”

And a reply from Will Sansbury reads as:

“I completely agree with this. In complex workflows, demoing wireframes to my team, the simple request to “back up a screen” means 30 seconds of dead time while I start the workflow over from scratch.”

And if it ends in something like “I’m embarrassed in front of my team.“, than you shouldn’t need more to start seriously think about it.
Forturnately, this only took me about an hour to implement, so here you have it: Home and Back button in the online and desktop viewers.

Bug fixes…

We have a couple of those, too.
First, the floating pane was transparent in the sketch theme. Thanks Gerhard W. for helping me on this one.

Secondly, it seems that master pages were broken when used for pop-ups. That’s embarrassing, but thanks to Lauran (from email conversation), this is all fixed now.

Until next time, I hope you’ll enjoy the exciting additions in this release. As usual, I’m all open for conversation so do let me know how can I make FlairBuilder work better and best for you.

Unkown, here I come!

Hi there,

Something that I wanted to write about since a while now is a sort of introduction into the process of prototyping. A couple of weeks ago I wrote an article about the reasons for which you should be prototyping. And since that article proved to be a popular one, it’s only natural for me to continue with some basic steps on how to get started with prototyping.

The basic and fundamental reason behind prototyping is communication and getting to an agreement over a to-be-built software application or website. The effectiveness of a prototype is measured by how many of your client expectations are fulfilled. First of all you need to know what your client wants and needs. So, first things first…

Plan Your Prototype

Depending on the complexity of your project and team, you might do this yourself or together with some other members of your team, like project managers or business analysts. Gather as much information as possible and as needed before diving into prototyping. Build feature lists, do site-maps, sketch if you like (and you should like that! ). Draw user work-flows and see how complicate they get. There are many factors that will influence the structure and the content of your prototype.

For instance, a complex website with complex workflows will require a complex navigation system. You’ll have to choose from the existing set of navigation patterns (top or side navigation, drop-downs, bread-crumbs etc.) or come up with new ideas. This will affect either the invested time or the structure of your prototype pages or both.

It’s important to get a good feeling and image of the desired result and start to have at least a couple of alternatives in mind for the most sensitive features. There are several ways to do the same thing and it’s essential to investigate as many as possible alternative paths before sticking with one of them. This means that your hydrodynamics should be pretty high in the particular problem your software is trying to solve.

Sketch and Draft

Prototyping is in many ways similar to programming. It has to be interactive, thoughtful and well structured. And while is not actually coding (if you’re not doing coded prototypes), it is nevertheless more expensive than whiteboard or paper sketches, for instance. That’s why prototyping is not always the first stage in product design process. There are other less expensive ways to start visualizing things before actual prototyping.

Paper sketches are, for instance, a great way to clear your mind and to focus on the big picture. I personally find it to be very effective for me to take my notebook and then step away from the computer to take notes or draw something, either in another room or even outside. I am lucky to live just across a little park, full of noisy kids. So when I take my kid there in the afternoon, I almost always take a pen and a notebook with me.

Whenever attacking a new subject, I always find it better to first visualize the boundaries of the problem on the table. Either when it was a college exam or, later, a big development task, I always felt more comfortable by knowing upfront how far I need to go before diving into the details of a very specific subject. Even if only superficially, being aware of the existence of a particular item will most certainly make you take better decisions and be more efficient.

So be sure to make one or two drafts first. Give your prototype a first consistent shape and get feedback. Or even if you don’t go the client to ask for feedback with your drafts, you will at least be facing something that is starting to resemble the final product and is already posing some problems: “Will this login box actually fit there?” or “Aren’t there two many links in this navigation side-bar?”. This type of questions arise fast when prototyping, while they may not necessarily be that obvious while sketching.

Dive Into The Details

When time comes, you need to get you yourself wet and step into more and more corners of your prototype. Depending on the time-frame and initially established purpose of your prototype, the level of detail will differ. Nevertheless, make sure that you identify and address those sensitive aspects that have the most weight in your prototype. Navigation, the above mentioned example, is something that significantly influence the structure of the prototype.

Be sure you are conscious of how much you are hiding behind generic text as “Lorem ipsum”. While generic elements are good from keeping your audience focused on what you want them to focus on, be aware that there’s also a danger that you are not offering them a chance to tell you something important (which eventually come later on, or when it’s actually too late tone taken into account), or to offer precious feedback.

And remember that details are not necessarily only visual. The entire apparatus behind a label or a number you put on a page may heavily influence important planning decisions. Small details like the number of similar products on a product page, or the number of comments of a user etc. have their development cost. So if you are filling space with such details and product management decides to take them out, you’ll have to be prepared and find ways to maintain the consistency of your prototype and its sense of completeness without those elements. The bigger the changes, the better you’ll have to adapt and come up with new solutions and reconfigure portions or entire pages.

Limit Yourself

Prototyping should be fast and cheap. A great way to maintain momentum in a project is by doing things at a constant and fast iterative pace. Prototyping is not, by any means, an exception. Spending too much time by yourself prototyping, decoupled from the rest of the team will only increase chances that the project will slightly go off track. Especially when someone else is waiting for you to deliver, the client or the stakeholders or the development team. Think carefully about how much you really need to put in a prototype. Half done parts will raise lots of questions. Be prepared to answer them or simply take out that part until you’ll be ready to provide answers.

Improvise and be as flexible as needed to achieve the desired results faster. Even if not everything is fully functional, most of the time is just O.K. Just do the bare minimum required by your audience (some types of audiences will need more than others, that’s true!). Remember that most of the time, prototypes are throw away artifacts. In the rare cases when you’ll do coded prototypes you might just reuse some of the code, but even then the code will quickly evolve and change. And in the end this is not the point of a prototype, to produce production quality code. It’s just a proof of concept and should be threated and priced as one. You will not ask lots of money for a prototype so don’t spend lots of time building it. Be pragmatic.

Should you identify other important aspects of the prototyping process or have things to share with us, please be sure to leave a comment and let us know!

Thank you!

Hi there,

This week I will be heading for Berlin for this annual European Conference of Software. I am very excited about it. There are very interesting peoples and talks in the agenda and I will surely have a lot to learn.

That’s why I didn’t want to put too much into this week release, just to make sure that there will not be hidden bugs I could not address quickly. Nevertheless, there is one thing in this release that excites me a lot.

Snap to Grid

One of the things that is very CPU intensive in FlairBuilder right now is the snapping feature. Although it lets you align objects nicely one near another, it also needs to do all these computations that can became pretty large in crowded spaces. Besides that, it also gets messy when moving small objects through those crowded spaces. It will snap in all directions and precise placing becomes very tedious.

Anyways, the fact is that following a genius hint from D. Bowles in an email conversation, I went ahead and implemented snapping to a 5px/5px grid in something like an hour or two (it actually took 5 minutes, but all the bells and whistles around it took a bit more ). Now, the entire positioning process is much more smoother and just feels better. I really hope you’ll like it as much as I do.

I enabled it by default because I think it offers a better experience. But, if you want to enable the old snapping mode, just go to the new Settings menu entry (I renamed the old View), and beneath that you’ll find a Snap to peer menu entry. Whatever option you select, it will be remembered on application re-start.

Bug fixes

We got a few of those.

It seems that when closing a pop-up from the X button, and not through the ‘Close pop-up’ action, the ‘Go to another page’ action was not functioning anymore. Thanks so much Gerhard W. for helping me on !

The ribbon bar was not catching up properly the theme of the project and the content was always displaying in the Sketch theme. Thanks Renee Davies for letting me know about this. It wouldn’t have made it in this release otherwise. I wouldn’t have made a quick bug fix release just for it, nevertheless, but still I’m happy it found out about it just in time. I don’t 4 digits version numbers.

One last thing, the Video Player component got all messed up when I added the Image import feature. Although Video Player is not yet fully implemented, because you can not take the video files with the FlairBuilder project file, still it’s useful as a proof of concept or it is actually functional when you’re demoing from your own computer. I will do my best to find ways for it to be functional on your viewers computers, too. If you’re using this component or would like to use it, please let me know what are your needs and we’ll find a solution together.

Thanks so much once again for all your great support and for helping me making FlairBuilder the best prototyping tool the money can buy.

Unkown, here I come!

PS: I’ll try to blog from Berlin and post pictures made with my brand you Canon 500D camera.