Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
What comes first? After the design has been outlined and approved, should a designer create pages in HTML and then hand them to a developer to add code? Or should a developer build simple pages that work and hand them over to the designer?
I've always done the latter, but recently worked with a designer who built an entire site in HTML and handed it to me to make it work. I found it saves a lot of time for 3 reasons:
The developer doesn't have to create all the form fields and rudimentary layout.
The designer doesn't have to rework all the "ugly" pages into something attractive, instead starting with a clean site which is faster.
The code isn't accidentally broken by the designer. I've found designers are more likely to break the code doing their work than developers breaking the design adding the backend functionality.
In short, if the designer does his work first, there's very little rework. I just make what already looks great actually work.
So which is best practice? See other plusses and minuses?
EDIT: Assume both designers and developers are already in agreement on the proposed design.
Wireframe mockups and visual aides are a great way to elicit requirements from end users. Giving the user something to look at and see helps to drive the design to where it needs to go instead of developers just doing the guesswork.
Also, UI design does affect your code. I think the biggest myth that we buy into as programmers is that we can just build a business layer and then spread the UI on like peanut butter. It never happens this way, so I am a big fan of having designers work with users early on and often. Having a visual design to work against is like TDD for the UI, and it helps to drive the process downwards.
Best practice is to try it both ways, see which way works best for your organization, then do it that way.
Occasionally try it the other way to see if anything has changed.
That way you get a solution tailored to your situation without worrying about ephemeral transitory things like "best practice".
As you can probably tell, I'm not a big fan of rules being handed down from on-high. Don't get me wrong, if something proves to be an advantage, I'll use it (agile, for instance, since it focuses you on immediate deliverables). But it has to be proven in the environment you work in, otherwise it's just something that worked for someone else.
I think it depends highly on how your views and code behind are set up. Some people will put a lot of logic into their views and others will have little to none. It will eventually just come down to your specific case.
In most cases, I agree, it will be easier to create the HTML first and include the back end programming later. It is essentially making a specifications document for you.
Once you've got your storyboards all worked out and approved, it's probably more natural to do more detailed "sketching" at the HTML level first. But I guess I'd also try to decouple the design and code as much as possible, so that the developer and designer can work somewhat in parallel. Two ways of decoupling are XHTML/CSS and "unobtrusive Javascript".
The developer and designer can work out the skeletal XHTML page structures they'll need from the set of storyboards. The designer then can use static mock pages to develop the CSS style sheets and explore the artwork. Meanwhile the developer can focus on generating the XHTML structures without style information. The big advantage (and goal) of CSS was to separate page structure from page appearance.
Another avenue to explore are "unobtrusive Javascript" frameworks like jQuery, whose goal is to separate the page's behavior from its structure, again making it easier for the developer and designer to work in parallel. By parallelizing these activities, it would be possible to incrementally deliver versions of the final product, both in form and in substance.
I would definitely go with designer first. If the coder does the pages first, he's forcing a design on the designer -- particular for a multi-page form.
Depends on the type of place you work at and the skill set of your teams!!
I worked for a Design Agency for many years where designers ruled as they brought in the biggest revenue stream and the web work was an add on to the services.
We worked very closely with the designers to make sure the designs met requirements and we not to off spec. The designs were a lot of the time used as sign off (don't get me started!!) and not much could changed once agreed by the client. The designers were also not that good at HTML,JScript,CSS etc so this was left to the developers to implement.
So in this case design was always done first which worked well, even if it was for the wrong reasons.
Well, assuming that the designer produces high-quality HTML and CSS (which is far from obvious, btw), the question boils down to: do you have 100% control of your HTML or not?
If you use a CMS, or a framework that likes to produce lots of its own HTML (like ASP.NET), then you have no choice. Trying to make the output match the designer's HTML is a pointless headache. You'll be better off with your original method.
However, if you produce all of the HTML by yourself (using PHP or, say, a lightweight framework like Django), it's better for the designer to produce the HTML first, for the reasons you mentioned.
Small nitpick: I disagree with reason #2. CSS-based design is all about taking "ugly" (that is, bare and functional) pages and making them attractive, without even touching the HTML. If the developer writes decent, semantic markup, it should be pretty easy for the designer to add his design on top (well... with some HTML hacks added, like for round corners and the like), since this is what he should be doing in the first place.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm inheriting a bunch of programs at work where the original author used Microsoft Visual Studio's data components (where a dataset, data adaptor, etc) are creating inside the design environment (from the toolbox or using wizards). This yields some semi-tailored (specialized for the data) classes, and also puts the SQL code into designer generated classes.
This is not how I'm used to doing things (I've always preferred to either unambiguously have a dataset, or create my own specialized class to hold the data and hide the complexity of the underlying data layer).
Does anyone have some good insight or links discussing the pros and cons of using Visual Studio data components?
(A side note, the original author also didn't comment very thoroughly and wrote, for my tastes, a bit too much "clever" code that is not easily interpreted, so I'm not inclined to think he knows any better than I.)
I suppose another way of asking is this: Does using the data designer components result in code that is "following best practices" and is maintainable, etc? It doesn't seem so to me, but I'm looking for input from experts.
[EDIT: Added some more context for clarification of intent]
If I'm right (and it looks like I am) about using designer components really being best suited for prototypes, etc, then I'm going to have to go have some tough conversations with the original developers and my manager. So I'd like to add more emphasis on "links discussing pros and cons" part of my question... I'm looking for something substantial I can use to support my claims that this style of development / code isn't the most appropriate for production use... Thanks.
In general visual components are for throwaway applications, POC's and spike applications, i.e. prototyping. This is for a couple of reasons; they are very quick to get together but a complete nightmare to maintain. I'm unsure of the size of your application but if it were me I would be arguing that in it's current form the cost of ownership will increase with time and therefore would look to more of a DDD style of development. Bin the data layer and replace it with a good solid ORM; NHibernate(preferred) or Entity Framework 4 (easier to get into). Drop that 'clever code' and start using the Kiss, Yagni, dry mantra. It might be difficult to get them to see the light but once it starts costing less they'll love you for it ;)
If you want some more reading in this area look at the following:
Skill Matter are a training facility that run open session and loads of podcast you can watch
A good book for both Dev's and managers to read is Ship IT, it looks at good project practices. As does anything on the pragmatic bookshelf
Martin Fowlers' blog for all thing DDD
Ayende's blog is great place for all things NHibernate
stackoverflow.com, this place rocks
VS data components purpose is rapid application development. From this point of view you can see its pros and cons:
pros: fast development, do not require much coding and knowledge. Good for small applications which will not be changed in a future.
cons: breaks Layer application design logic (add here all pros of such design) combining all in one file.
As a result almost impossible to replace datasource dynamically. Makes more complicated large application support. DI, TDD - it something mysterious using it.
Actually it's a very wide question.
I'd recommend to read more about N-tier application development and Test Driven Development
Hope this help
I wouldn't even go so far as to say that the designer DB components are good for POCs or prototyping. Those components are in Visual Studio primarily as a sales pitch for the framework, so that Microsoft can say "wow, look how easy it is to create a data-driven application with .NET!" They should have been removed years ago, IMHO.
However, don't confuse the designer components with ADO.NET (i.e. DataTables, DataSets, DataReaders, DataAdapters etc.) itself. Since the app you've inherited was built around the designer components, that means that it was also fundamentally built around the ADO.NET components. You can (and should) get rid of the designer components, but you shouldn't necessarily get rid of ADO.NET as well.
I personally think you are definitely on the right track, BUT imho it really depends on what you already have and what the plans are for the future of the product.
I have seen production code that uses just as you are talking about and works fine, and is somewhat easily maintainable.
There are even some great drop in modules from very large companies such as Telerik that fall into the same category of development that you are talking about.
I think what really is an important factor to your employer is: what can you use to get the job done in the fastest most efficient way. I would say that in general though, the "drag and drop" tools straight out of the box are not very good for long term enterprise level applications.
Here is an article by Charles Petzold that may provide more "expert" credential information for you.
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
I work in a small and young team of developers and we have problems that we are not sure how to solve.
On previous projects every developer have been working on tasks that were based on use cases. So, upon setting the system architecture, each team member worked on user interface and business logic of tasks assigned to him.
This kind of organization gave us the problems with UI. Each developer had his own logic about how UI should look like, where buttons should be, etc etc... and even if we've had one css designer a lot of refactoring had to be done in order to make web site to look compactly.
How do you deal with this issue?
Do you split tasks based on layer, not on whole use case?
Do you use some technical solution to achieve this or is it just written standard that every developer need to follow?
Thanks
Everyone has their own style and it would be difficult and a waste of time to define a standard that would get everyone to draw the UI in a consistent manner. Instead, elect your best UI designer to do what he does best and design the UI for the whole system. Funneling all UI changes through the designer would be difficult so just let your developers "mess it up" as they implement new use cases and just have your designer clean it up before the release. It shouldn't be hard for him/her to rearrange the existing forms and bring some consistency back to the UI.
I've found this 12 Standard Screen Patterns article very useful.
A solution might be to create sketches of all screens of your application, have them reviewed by an ergonomy-expert to correct the biggest mistakes, and, only then, give them to your developpers.
This way, they would know how the screens they are developping should look like -- there will still be a couple of differences in the end, but those should not be "big differences", and should be eaiser to fix.
And this would mean not each developper has to imagine what the perfect screen would look like : each one of those would be coherent with the others.
Adopt the tried and tested MVC system, let the view be decoupled from the business logic. Then ask a UI designer to produce sketches and work to that. UI's are something best done top-down from my experience. The user gets an overall view before being presented with all the details, defining and capturing this hierarchy makes good UI's. Coding of business logic is done as you mentioned on a use-case basis, mostly bottom-up and this is where the code falls out of sync with the UI.
Designate one person (preferably someone with graphic design experience, even if they're not really a programmer) and give them the authority to make cosmetic changes to all forms, pages and controls at any time, and have them be responsible for the overall look and feel of the application.
As far as metrics go, keep track of how much time this one person has to spend "fixing" each programmer's work, and make sure the programmers are aware of these numbers. The idea is to encourage them to make their stuff look like it should from the beginning, but also not to do weird things based on what they think stuff should look like. I've had to spend more time undoing my coworkers' bizarre design choices than anything else.
Don't be afraid to have outside sources review the design work of each programmer. It's very common for programmers to 1) produce horrible-looking UIs, and 2) believe the UIs look fantastic. You should do what the Army does with boot camp: break them down completely right from the start, so that you can build them back up again the right way.
Part of the problem with creating your own written standard is that while well meaning, there could be mistakes or better ways to do things than what's been standardized. For example, where I work, the standardized cancel button does nothing when you click on it (it's been wired to Reset).
Instead, I recommend choosing existing standards, such as The Macintosh Human Interface Guidelines or Windows User Experience Interaction Guidelines. Even if the standard is wrong, it's rarely profitable to deviate from widely established conventions.
Then pick up some good books for the developers, such as "Designing Interfaces: Patterns for Effective Interaction Design". Good user interface design is partially a matter of good taste, and while not every developer will be interested in the subject, it's in your best interest to help them improve.
Next, empower your QA team to file bugs when the interface for one product is inconsistent with another. The developer can then either standardize or justify the deviation if he has a reason. We do this; it works pretty well.
Lastly, go over your existing products and get a consensus on how their interfaces should be unified. Bring in (and keep) a usability expert if you can. I've seen good ones do amazing work.
There really is no clear solution for how to deal with UI problems. There are however several approaches one can take to combat the problem of having things become too complicated:
Use cases are usually cross disciplinary in nature, thus the responsibility to get a use case done should be split between the people who can implement it properly. Programmer and designer type of people need to cooperate.
Everyone in the team needs to keep in mind seperation of concerns, i.e. things that can be seperated must be kept that way preferably as early as possible. There are so many ways to do this: e.g. apply MVC pattern in your project (which is a very wide way to put it). Presentation and logic should be seperate so that changes in one layer should not affect the other.
Someone needs to be responsible for the overall UI design so it is consistent throughout the application. Preferably someone who is both a graphic designer and has some insight in usability. UI design is something that needs to be planned along with the use cases and revised constantly as development goes on. Consistent UI is very important and developers need to be on board on it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We are currently starting a bigger project. What're your suggestions for best practices of workflow?
We are planning to rebuild from scratch (the existing product is outdated by years, regarding visual and internal design and programming). While the product functions (a Rails based web project) are already set, the question is: What is your workflow from here on? The most interesting part is: How and when do you do your screen design?
We are planning to do it in the following order:
"Pencil and paper" screen design: Just layout what the screens should look like and visualize the functions and visitor pathes
Hand out the layouts from point 1 to the designers, have a talk to them, and let them work in parallel to programming on the designs
First implementation, simple color-less HTML layout based on point 1 (automated tests, functionality, BDD, TDD)
Integrate the designs with the product prototype
Work out the rough edges together with the designer team to finalize the product
Release a beta product for the customer to test
Do you have similar workflows? Are there suggestions for improvements? But the most important for me: How exactly do you do point 1?
While this is not exactly programming-related I still think this should belong on StackOverflow as this is important for anyone doing bigger projects. From the past we know that good screen design is always a critical and hard point if trying to do that while programming, and even harder to deploy it after the prototype application has been created.
Update: I found Balsamiq Mockups to be a very helpful tool to do the mockups. Still there's an open question how one would best visualize visitor pathes.
Update: We had been successful using Balsamiq Mockups to create a design pleasant to the customer and we managed to successfully integrate this into the existing web content. The customer is so comfortable with the new ideas that he is planning to redesign the complete web site.
I like your workflow. It should lead to a decent result.
A few ideas here:
Let the designers know and understand your presentation model. What pages there are, what information and control elements will they have, what is the role of each of them, what is the purpose of the page and what message should it communicate to the user. If you let the designers work alone then they will design something to reflect their vision of the project and not your design. You'll end up redoing everything or trying to adapt one part to the other.
Users will only see and understand design. They know nothing of implementation. If they see a button they will think the feature is there. if you plan to go agile while cooperating with the users during development, hide out elements that are not implemented yet. Feed them results one step at a time.
If you can have users nearby do screen design together with them in iterations. There is not much work for designers yet, when you are basically deciding on the layout. All those colourful effects and polished buttons should be done after the layout is stable. Otherwise it will be a waste of the designers work.
I really like the model of extreme programming. When dealing with new products user requirements can quickly change over time and this is a proven method which keeps the design "up to date".
Have the users write up functions that they want for the application. And have the designers agree upon a general layout.
Write up a general wire-frame that both you and the user agree upon, I like to do this in smart draw or some sort of rapid gui development platform. (no functionality at this point).
Write the code for the GUI based upon the wire-frame and write sequence diagrams and class diagrams.
Based upon these design start to fill in the functionality behind the GUI
Release betas throughout the process of adding functionality to select users who can help guide future development
The benefit of this design is that at any point in time you can re-work the GUI and incorporate new functionality. The idea is to have a general plan at the beginning that can be adapted as user requirements change.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have been looking for a collaborative tool for developing functional specifications. I am looking for the ability to:
Have multiple users contribute to the specification.
Provide some form of traceability, which could be done manually if needed.
Provide users with the ability to add comments and notes.
Upload and display Visio documents
Upload and display mockup screens using Balsamiq Mockup.
My initial impression is that using a wiki could be a good tool for this task. Does anyone have experience with using a wiki for creating functional specifications? What would be the pros and cons to using a tool like this as opposed to a requirements management tool?
Your input is greatly appreciated!
It's possible to do what you describe, to develop requirements in a collaborative way, in spite of using a wiki. Nothing about the wiki paradigm assists in this process.
I managed a wiki on the Zend Framework project to track proposals for components. They're still using it. Proposals are different from functional specifications, but the usage is similar enough to your question that I think this is relevant.
A wiki doesn't take care of itself. Unless you have someone responsible for managing it and making sure there is some structure and consistency, it quickly becomes a mess. The real-world analogy would be to hand each of your team a blank sheet of paper and tell them to write up their part of the requirements. Problems with this are:
Every contributor has to make up their own document structure, and write about different things in a different order. So it's impossible to compare one page to another.
There's no "index page" to organize all the disparate contributions. No one wants a page to "fall through the cracks," but in a wiki that's the default destiny of any page as soon as it's written.
There's no feedback loop to make sure the writing actually gets done.
The way to make it work is to apply some process to the project, and use the wiki in accordance with that process.
Give people the ability to create a new page in the wiki, but only through an interface that automatically links the new page into the right index.
Define a lifecycle for documents, so they are sure to be drafted, reviewed, and approved at the appropriate stages.
Provide a template for a new page. Provide the section headings that you need in each of these pages, and make part of the review process a confirmation that head section has been filled out adequately.
"What would be the pros and cons to using a tool like this as opposed to a requirements management tool?"
While it seems like a great idea, what you run into are people who can't and won't write.
People who can't write -- well -- can't write. They can't communicate with an email or a wiki or any medium outside voice.
Some people are "disorganized". Actually, writing is too linear and they don't think linearly.
Some people don't get the "write to your audience" and write stuff that's incomprehensible.
Sometimes you can't even figure out what they're talking about, much less what they're writing about. They talk in jargon or code. They don't know much but insist on being heard.
Some people won't write.
Some people refuse to make commitments. Even in a wiki where it can be retracted. They feel they must pre-discuss everything.
Some people are in the habit of doing everything by giving direction to someone else. They either don't write for themselves, or, they make people stand around in their office and listen to them talk and type.
Some people are generally toxic on any kind of project. They spring new requirements at the last minute. Their first response is "that will never work". They don't brainstorm well. When they say it work work, and you beg them for an improvement, they don't have one. They just know it won't work.
My experience is that only programmers can use a Wiki successfully. And only senior-level programmers.
N00bz don't have enough experience to sort out requirements from design from rumors and management fluff.
N00bz don't always have the language skills to write clearly. They may eventually, but one look at their Javadoc comments indicates that they're struggling with the "clarity" part of writing.
It's very appealing. I'm hoping for people to get better at using wiki's because I think it could have a lot of advantages over more traditional approaches where one person interviews everyone and writes things down. But it requires a level of confidence and skill in communication that few people seem to have.
Consider researching Fog Bugz. They tout themselves as the best of the
best for project management. Considering Joel's history I'd give them the
benefit of the doubt. They use a wiki in the way you've just described.
I would suggest signing up for the free trial, if you're serious.
Depending on the size of your project, buying it might be a very good
option.
At very least you could look at how they've structured it, or read the
forums for ideas on how to build your own stripped down version
Specialist tools help keep things on track and introduce a fixed work-flow. This is kind of the point, keeping things focused and functional. Using generic tools like a Wiki might be great for a bunch of programmers but introducing one for 'mixed-mode' work might be bad:
Things can creep and get off-track quickly
Communication can be lost in the medium
Look at things like Basecamp. They can be thought of as an applied wiki, or collaborative tool. A generic tool for specific purpose needs refining. I don't know if MediaWiki or others have enough customization to keep things clean and focused.
Maybe gather the requirements for your requirements management tool (recursive I know) and what aspects (communication aspects) you can take from the wiki culture and an open-communication mindset. If neither requirements management tools or wikis fit the bill, look at building one. Might be the next big thing. It feels like saying Could I use a wiki instead of Bugzilla?
A fixed work-flow webapp for requirements management with an open-communication emphasis that allows people from many roles to see and understand might be good!
We have used TWiki and now FosWiki in that context. There are many things one gets for free (version control, access control, Web-base access, searches, remote management, security patches, ...). In a few minutes, one can define:
a table defining requirements attributes,
which creates interactive forms with field selection and validation (where you can also document discussions and rationales, embed images, attach documents, link to other requirements...),
and then queries on these "requirements" and show them as tables that can be sorted, filtered, printed, reported against, etc. (e.g., http://jucmnav.softwareengineering.ca/ucm/bin/view/ProjetSEG/JUCMNavRequirementsVer2).
Obviously, one can easily use hyperlinks and Wiki links along the way. FosWiki also has features that can be used to enforce specific workflows, if needed. It is also easy to support forms for use cases and other paradigms (we have done this in the past, and that works generally well).
Wikis such as FosWiki are extensible and one could develop further modules for addressing weaknesses related to traceability management and impact analysis, table-based modifications of requirements, overall packaging, etc.
As a middle ground between a free-form wiki and a requirements management tool, consider using a structured wiki like Foswiki. I haven't done any formal requirements management (with a wiki or otherwise), but I have used TWiki (the predecessor to Foswiki) for other tasks, and it permits you to define a workflow, form fields, and so on as you need them, while keeping the flexibility of a wiki when you don't need a formal structure.
I agree with all (most) of the people above - use of a wiki may sound ok, but wiki's are meant to be present information and be updated as needed, not to be used as an interactive project management tool. I would strongly suggest SmartSheet (I'm a strong advocate of the product) - it provides a spreadsheet like interface where you can store multiple files per row/task, send out automated updates to users and maintain specification revisions...
The other approach could be the use of Google email, docs and calendar - a free friendly way of team interaction....I would shy away from issue/bug tracking tools for project management - they tend to have differ on focus: PM tools on the entire project/resource/timeline and Issue tracking tools for specific entered issues....
This may be a bit old now, but I am currently using Atlassian's "Confluence" and it's been great. I currently work as a UX engineer playing the role of "Product Owner" within an Agile process. I can document requirements for discrete interfaces, allow for multiple users' feedback and comments, and intertwine each interface with other interfaces within a larger context (e.g. user story). Everything is very dynamic and template driven. It's suiting my current needs very well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
When prototyping initial GUI functionality with a customer is it better to use a pen/paper drawing or to mock something up using a tool and show them that ?
The argument against a tool generated design being that the customer can sometimes focus on the low-level specifics of the mock-up rather than taking a higher level functional view of the GUI overall.
Always start with paper or paper-like mock-ups first. You do not want to fall into a trap of giving the impression of completeness when the back-end is completely hollow.
A polished prototype or pixel-perfect example puts too much emphasis on the design. With an obvious sketch, you have a better shot of discussing desired functionality and content rather than colors, photos, and other stylistic matters. There will be time for that discussion later in the project.
Jeff discusses paper prototyping in his Coding Horror article UI-First Software Development
Click the "Watch a video!" link at twitter.com to see an interesting take on the idea from Common Craft.
The "Napkin Look & Feel" for Java is really cool for prototyping. An actual, functioning, clickable app that looks like it was drawn on a napkin. Check out this screenshot:
Seriously, how cool is that?
I would suggest you sit down with your client and use a tool like Mockupscreens and develop the UI interactively. A benefit it has over Napkin LAF is that it does not require coding, or indeed development tools of any kind
Check out Balsamiq
It does the "THIS IS NOT A FUNCTIONAL APP" napkin view very well and is easy to use.
Has a full featured demo you can try out online and as an added bonus you can email your XML to your client and they can tweak it and play with it and email it back to you without having to have a license.
There is a book called Paper Prototyping which details pen and paper drawing and what you can gain from it. I think it has a lot of benefits, particularly that you can, very early on (and easily), modify what the end result will be without much effort, and then start off on the right foot.
A basic paper version is the way to go for an initial mock-up. It's been my experience that if you do a "real" mock-up, even if you explain to the customer that it's a non-functional mock-up, they are confused when things don't work.
Bottom line: keep it as simple as possible. If it's on paper, there is no way the customer will confuse it with a working product.
For the first draft, I prefer to use graph paper (the stuff with a grid printed on it) and a pencil. The graph paper is great for helping to maintain proportions. Once the client and I have come to a conclusion I'll usually fill in the drawing with pen since pencil is prone to fading.
When I actually get around to building the digital prototype, I'll scan in the hand-drawn one and use it as a background template. Seems to work pretty well for me.
I think it is best to start with Paper/Whiteboards/White walls.
Once you have the basic structure, you can move it to Visio with the wireframe stencils
(Download a Stencil Kit)
(Visio Stencils for Information Architects).
Or you could use Denim (An Informal Tool For Early Stage Web Site and UI Design) with a tablet PC or Wacom tablets to design the GUI and run it as HTML website.
WireframeSketcher is a tool that helps quickly create wireframes, mockups and prototypes for desktop, web and mobile applications. It comes both as a standalone version and as a plug-in for Eclipse IDEs. It has some distinctive features like storyboards, components, linking and vector PDF export. Among supported IDEs are are Aptana, Flash Builder, Zend Studio and Rational Application Developer.
(source: wireframesketcher.com)
I've recenly used a windows App to prototype an application to a customer (the final interface has to be integrated into a website).
At first people thought that it would be the last version and they started to make very heavy criticism from the way controls were displayed to the words I had used (terminology and stuff) and the meeting time ended before we could even discuss the functionality itself.
That discussion dragged on for days and days until I told them that, being a mock (and not a final application) all input is welcome but we had to focus on the functionalities first and then we could move on to look and feel as well as terminology issues.
From thay meeting on I am always terrified of prototypes and mock-ups... Perhaps I should just have given them something made in visio instead.
You can try out ForeUI, it allow prototyping with different styles, what's more, it can make interactive prototype and run it in browser.
For a non-installation browser based tool you can try draft-it
It's free - and if you have a gmail account - no registration is needed.
Makes interactive/Step by Step Or Slide Show- prototypes. You can share your protoype with anyone you choose by just sending a link.
Works for us ...