Direct to Code Wireframing

13 Sep 2010 - 7:36am
4 years ago
12 replies
1866 reads
smitty777
2010

Hi all,

We are having a lively debate on the use of direct-to-code wireframing , and I was hoping I could get the perspective of the IxDA community on this topic.  Some are arguing that using a wireframing tool that creates the code is a mistake, as the code will be sloppy, and even thinking along these lines will force you to create wireframes that are at too high a level of fidelity and that focus on features and minutiae.  On the other side are the folks that say that wireframes are a waste of time unless you are actually creating code that I (the programmer) can use.  Besides, if you are coding the wireframes, they will look exactly the way you want them to. 

Also, for those on the pro- side, what are some tools you've used successfully?  HTML?  FLEX? ...

Thanks!

Bill

 

(full disclosure: also posted on UTEST for the UX perspective)

Comments

13 Sep 2010 - 9:05am
jasonmesut
2010

My nervousness is that you might remove the sketching or prototyping phases where you explore more tangible interactions quicker. Working in code can limit you to what the code base can do, rather than concentrate on the interaction. It's all about modes of working to me. Sketching, prototyping, detailing, communication. Certain tools take you too far ahead in the process and have you obsessing around the wrong level of detail.

I see the advantage from a spec point of view (ie, avoid some level of spec) and translation from ideas into delivery, but some of the thinking is still lost unless you write it.

Chances are that developers will have to rewrite any code anyway to optimise it for actual use.

13 Sep 2010 - 10:10am
aZippel4iD
2010

My personal view is "not all wire frames are created equal". If you are using the wire frame concept to develop optimized code you are trying to get to the moon in a rowboat. I doubt the need for which wire frames were developed and made popular had anything to do with optimized code. My personal practice is to use wire frames to flush out relationships between data prior to developing optimized code. To me, development comes in stages, just like dating. Where wire framing could be viewed as the kiss on a first date. Where you sort out what you expect and what you anticipate. Optimized code is the marriage ceremony where you build for the long haul. Both could be viewed as seperate and related parts to a happy life in "who-ville" ;)

13 Sep 2010 - 10:22am
gef05
2010

I recommend you pause and ask folks what they think the purpose of a wireframe is, and how it fits into your development life cycle. From a lot of what you describe, it seems that people have differing opinions about the "what" and the "why" of wireframes.

The wireframe will continue to be a rope in the development tug-of-war until you all agree on some basics.

13 Sep 2010 - 1:05pm
tessa
2008

It depends on the project, the org construct and the collaborative aspect/ability of the team. Its that simple. All the arguments are valid, depending on the situation. It is less about the tool, more about the team.

On Mon, Sep 13, 2010 at 8:01 AM, smitty777 <wschmidt@nbme.org> wrote:

Hi all,

We are having a lively debate on the use of direct-to-code wireframing , and I was hoping I could get the perspective of the IxDA community on this topic.  Some are arguing that using a wireframing tool that creates the code is a mistake, as the code will be sloppy, and even thinking along these lines will force you to create wireframes that are at too high a level of fidelity and that focus on features and minutiae.  On the other side are the folks that say that wireframes are a waste of time unless you are actually creating code that I (the programmer) can use.  Besides, if you are coding the wireframes, they will look exactly the way you want them to. 

Also, for those on the pro- side, what are some tools you've used successfully?  HTML?  FLEX? ...

Thanks!

Bill

 

(full disclosure: also posted on UTEST for the UX perspective)

(((Pleas
13 Sep 2010 - 4:01pm
jkantro
2010

As some of the others stated it really depends on the project, but not only the project. Find out what your team prefers and how the coded wireframes will be used. You should also ask yourself, am I comfortable and capable enough to produce coded wireframes. Lately I've been doing a lot of HTML/ CSS 3 wireframes, restructuring them for development and then the developers have their way with them. Usually it works out well. Bear in mind that I've only done this with small teams and I am quite versed in HTML 5 and CSS 3.  

I would strongly recommend not using Dreamweaver or Flex to create coded wireframes if they are to be used further for development. Dreamweaver generates some pretty unclean code that developers will find a pain to look at. It also produces some verbose code. Flex is quite verbose as well. This is especially true if you use the Flash Builder GUI creator to create the layout. MXML in general should not be used to create coded wireframes, unless your building a Flash app. If you are going to create coded wireframes, the best route is to hand code it in HTML and CSS 3. 

 The case for border: 1px solid black;

Code is flexible and can act as a great communication bridge between UX and developer. It's a developers native tongue. It's as simple as that. If you know CSS and HTML well enough to talk to programmers about layout and interaction behavior then you already have a head start on any web application, site, etc. While you can get caught up in coding features, and minutiae easily, this is why coded wireframes are usually done in layers. The iterative process can still be applied. Start with structure, then layout, then black borders, then necessary navigation and description text. As requested changes come in, apply them. Coded wireframes shouldn't go beyond black and white. Once they do then you start moving into higher fidelity wireframes. It's important to remember that developers can take HTML and CSS and do a lot with it.

13 Sep 2010 - 4:03pm
Mike Starr
2009

I've done wireframing in the same development environment as the developers; they were developing the application in Microsoft Visual FoxPro and that's what I used to create the wireframes. I'm not by any stretch of the imagination a programmer so they weren't fully developed but it certainly makes it easier for the programmers to deploy.

13 Sep 2010 - 11:29pm
ptamzz
2010

I think that unless the program has some kind of intelligent feature, it won't always give you the desired codes. Will it?? At some point or the other, manual coding will always come in.. which would be harder than coding yourself from the start. Talking about wireframes, I think a code generated would not be design-friendly. All you can get is a simple grid kind of layout. Is it really worth it??

14 Sep 2010 - 2:28am
dom.latham
2010

I think it is a good goal. Take the example of 'Usablilty' that has always been framed as this problematic relationship between the designers and the developers. Desigers make bad code, developers make bad UI. The aim for me is to have developers understand the design process better and enable designers to play with the production code. If a designer understand how CSS works there is no reason why they can't change a colour value or a border with themselves. Pragmatically this makes for less time spent trying to communicate between one-another, more time spent building great stuff and more scope for iteration in between.

Why not get the designer and developer working on the wireframe together? First they make some pencil sketches together. Then produce quick HTML formats. The developer learns something about the design process, the designer learns something about the technology. The partnership is continuous from wireframe to production code.

15 Sep 2010 - 10:50am
smitty777
2010

I find the thought of the designer and coder working on the same app intriguing.  This could be a very fruitful approach, depending on the team/app/environment.  

The one sticking point I would have about this approach is the lack of flexibility. Specifically, the inability to create branches.  One of the things I like best about wireframes is that it allows me to explore multiple design concepts.  I can create two or three different options in Visio with a simple cut/paste in minutes.  Also, the simple Visio diagrams have allowed me to wireframe on the fly at meetings, something I don't think would be possible using code. 

14 Sep 2010 - 9:14am
Paul Pinkney
2009

This is a great question, and after coordinating designs with everyone from visual designers to developers, I feel compelled to share some things which you should, at least, consider:

1. I have not seen any auto-generated code that is solid semantic mark-up, which can cause you problems with accessibility, performance, page fluidity, and many other issues.  This is just my experience.

2. As a general rule -- and I am generalizing -- developers are obliged to create accurate, high-performance, bug-free code.  They are generally <em>not</em> interested in developing or, at least, obligated to develop software that is accessible, pixel-perfect, conforming to style guidelines, free of interaction problems, and the like.

3. I have worked in shops in which designers threw Photoshop files, JPGs, or something similar over the wall to developers.  Because of the differences in emphases and priorities between interaction designers and developers, the results were generally disastrous.  Of course, this is the extreme end of the spectrum, but hopefully, you get the point.

4. All that said, I strongly recommend the interaction designer create the HTML and CSS.  I know for some IxDs, this might smell and taste like coding, but in my experience, without the IxD doing so, the user loses -- in some cases, a lot -- and that's what we're here for:  to advocate for the user.

5. Some tools might create a good start to HTML and CSS, but I would never leave to the tool to do so.  I'd always check its work.

6. I have even created unobtrusive JavaScript widgets myself, not leaving that to developers either.  I know I'm a picky SOB, but again, developers general won't think to or won't know how to make sure the interactions are free from problems.  And it can easily be argued that it's not their job.  For example, I created my own suggestion box (auto-completion widget) years ago.  You've probably seen many examples in which this type of widget had major usability issues.  Even the one in iTunes (the song information editor) has problems, because it forces letter casing, despite what the user types.  By creating my own, I was able to test it and discovered problems I coded.  It was a very iterative process before the user even saw it.  As another example, consider an icon list that is supposed to act like your normal "select" HTML list.  Would a developer think to make sure Alt-down-arrow pops up the list for personas who use the keyboard extensively?  Not likely.  And I know this is <em>way</em> too close to coding for some.

7. My bottom line is this:  If you have it in you, and it's practical in your organization, create as much as you can for the user, because it's in your best interests, and yours are the user's interests.  I like dom.latham's suggestion of partnering with developers if this is not possible or practical.

8. I'd say the same about graphic design.  Do it yourself to get the right visual weighting, etc., but if that's not your forte, partner with your graphic designer to ensure the highest measure of usability.

Hope this helps, or at least gives you food for thought.

14 Sep 2010 - 1:03pm
smitty777
2010

Thanks for your thoughtful answers, all.  I actually have a presentation on this topic I have to give soon, and your responses gave me some great food for thought.  I tend to side with Jason, that the wireframes provide the ability to rapidly turn over ideas without having to worry about the way the code looks.  That's why we have wireframing tools that look intentionally sketched, right?   

On the other hand, I have actually done some wireframing in FLEX which went right to code, and the results were spectacular. The UI was put together rapidly and easily.  We even did multiple rapid iterations before the SWF file was handed over to the developer.  And the best part: the UI looked *exactly* the way I wanted to, to the pixel.  

So, it's fast, easy, and seemed to produce really good code.  The only downsides I can see is that the resulting wireframe is *too* perfect and that not all our apps are FLEX .  Folks will tend to focus on drop-downs, buttons and wording instead of what they should be getting out of a wireframe. 

So, I'm really torn.  There is  pressure from the developers to "quit wasting time" with those wireframes and actually build something useful.  OTOH, I can't help feeling like something will get left behind with the direct-to-code approach. 

16 Sep 2010 - 2:23pm
Rahul Choudhury
2010

Don't use a wireframing tool. Write prototypes directly in HTML. The tool we're developing that IxDA reported on a little while ago (http://www.ixda.org/node/26367) is designed exactly for what you're describing and offers a great web-based environment for writing HTML based prototypes which you can then immediately share and collaborate on. You retain 100% control over the generated markup, although we do make several things easier for you by offering a prototype-specific set of HTML tags (http://quplo.com/flow) like "page" and "layout", which makes developing prototypes faster.

Quplo will help you find the middle ground between "wasting time" with wireframes and building something immediately useful. On top of that, you're able to export your Quplo prototypes directly to ASP.NET MVC projects (which will make your dev team very happy) and we're working on other languages. We're also working with Balsamiq to enable importing directly from Mockups.

Check it out and let me know what you think: http://quplo.com

Syndicate content Get the feed