Comments on: Sustainable UI Prototyping http://linowski.ca/thoughts/2009/11/sustainable-ui-prototyping/ Fri, 15 Jul 2011 03:13:19 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Jakub Linowski http://linowski.ca/thoughts/2009/11/sustainable-ui-prototyping/comment-page-1/#comment-110 Jakub Linowski Fri, 04 Dec 2009 18:16:00 +0000 http://linowski.ca/thoughts/?p=208#comment-110 I'd agree with the value of spiking. I guess UI libraries / pattern libraries such as YUI and jQuery UI in some ways have been emerging to make it easier to start off projects and prototype as opposed to reinventing the wheel. I wonder if the barrier to these libraries (both pulling and pushing ideas) could be lowered as part of the design tool used. I'd agree with the value of spiking. I guess UI libraries / pattern libraries such as YUI and jQuery UI in some ways have been emerging to make it easier to start off projects and prototype as opposed to reinventing the wheel. I wonder if the barrier to these libraries (both pulling and pushing ideas) could be lowered as part of the design tool used.

]]> By: Fredrik Lindersson http://linowski.ca/thoughts/2009/11/sustainable-ui-prototyping/comment-page-1/#comment-109 Fredrik Lindersson Mon, 30 Nov 2009 23:21:20 +0000 http://linowski.ca/thoughts/?p=208#comment-109 Nice post. Personally I like an approach where in the initial faze of rapid prototyping (called spiking) you do not have to consider reuse of code (nor the aesthetics of the UI). This would mainly be done to prove or disprove a concept as early as possible and also help the team realize what parts of the project will be difficult or time consuming (also helps in estimating the projects time frame for clients). I´m all for pretty and reusable prototypes with a unified UI but over the years I have found this reserved for projects with higher budgets, lots of alloted time or (in worst case) teams with bad communication skills. Keeping a library of code/graphics/components updated is time consuming. In the end prototypes are most often created to test something unique and new (well at least from my perspective coming from flash/actionscripting). Therefore it will most likely not exist in your library. In my opinion early prototyping should be about interaction and feel. Looks either come in later or when the lifespan/target audience of the prototype or the budget of the project warrants it. Nice post. Personally I like an approach where in the initial faze of rapid prototyping (called spiking) you do not have to consider reuse of code (nor the aesthetics of the UI). This would mainly be done to prove or disprove a concept as early as possible and also help the team realize what parts of the project will be difficult or time consuming (also helps in estimating the projects time frame for clients).

I´m all for pretty and reusable prototypes with a unified UI but over the years I have found this reserved for projects with higher budgets, lots of alloted time or (in worst case) teams with bad communication skills. Keeping a library of code/graphics/components updated is time consuming. In the end prototypes are most often created to test something unique and new (well at least from my perspective coming from flash/actionscripting). Therefore it will most likely not exist in your library. In my opinion early prototyping should be about interaction and feel. Looks either come in later or when the lifespan/target audience of the prototype or the budget of the project warrants it.

]]>