I'm interested in how to develop Web-GUIs using test-driven-development.
Especially I'd like to know if there are any guidelines/hints/best-practises on how to design Web-Frontends (i.e. the HTML) in order to be (automatically, of course...) testable? (in classical UI-developement there are patterns such as MVVC which support TDD and automated testing)
The are very similar patterns for web development as there are in desktop development. But, and it is a big one, the web is stateless. This sounds obvious but I think it clearly defines the boundaries for testing.
There are many, many popular incarnations of MVC for the web. However, in some web technologies it is hard to separate out pure UI (HTML, CSS etc) from code. You can always fall back on more of an MVP approach, which is like MVVM except the view is passive (won't respond to events and rebind). These patterns should cover you for the main UI logic of the application. All of these patterns can be used with TDD.
If you want to then go up a level, you are into tools like Selenium. These tools allow record/playback of user interactions with the web ui. However, if used casually, they can lead to brittle tests that break when the layout changes.
Hope this helps.
I don't know of any specific guidelines, but writing clean, semantic HTML and making appropriate use of CSS class and IDs is normally sufficient.
Related
I'm making a web application that is quite a bit more complicated than others I've produced in the past. I think before I go much further I should try and get down a plan for the application as I currently have it.
I recently took a course in UML, but that doesn't seem particularly appropriate here - as while I'm using an object-oriented framework it is really the relationships between the Models, Controllers, Actions, Views and URL mappings I'm looking to document.
So my question is - Are there any software design applications out there that are particularly useful for documenting the structure/functionality of an MVC application?
On the basis of this I'd be hoping to write a testing plan.
Documentation is not for the creation of "testing plan" (whatever what means to you). If you want to test your application, you should have been writing unittests all along.
This sort of documentation is meant to alleviate the confusion in larges-scale applications. And the use of UML would be appropriate in this case, though there is no rule, that states you have to use all diagrams. But in your situation class or component diagram might be quite useful, with some sequence diagrams to illustrate more confusing parts of the application.
Also some ER diagram might help, if you have a complicated DB structure.
I've played a great many MMORTS games such as Evony, Dragons of Atlantis and Kingdoms of Camelot. They all have some great features and a great many not so great problems. Simply for my own interest I wanted to try my hand at writing something similar. I don't intend to even try to compete with the big boys but I wanted to write it in a professional and scalable manner as if it was intended for eventual commercial release.
So that's the background that leads into the question. I have been looking at various frameworks and libraries that would be suited to this style of game. However there is such a plethora of options that my head is now spinning. I would like to get some input as to what other people think are the best options. I want to try and write this as a cross-platform / cross-browser webapp that can later be converted to a "Native" app using something like MoSync. I want to stick with HTML5, CSS3 and JavaScript technology.
Some of the things I am sure I want are:
It must be scalable (ie able to handle a significant number of simultaneous users)
I prefer to work with some sort of MVC framework (I am used to working with Joomla MVC and have been considering backbone.js for this aspect)
I am no JavaScript guru but will most likely want to work with jQuery (mostly in relation to client side views)
I like templates but am completely lost which template system to go with (ie mustache, handlebars, dust etc). I think my choice in this area will ultimately come down to which framework I end up with.
Chat is an important aspect of MMORTS games and I am thinking of using Node.JS and Socket.io (or NowJS) for this.
I have also been looking at Redis for key-value store.
At this stage I have abandoned the idea of using jQuery Mobile as initial tests have caused more headaches than they have solved.
So my front runners are Node.JS for server side JavaScript (possibly with NowJS to implement chat), Redis for key-value store, backbone.js for the MVC framework, mustache (or maybe LinkedIns fork of dust) for templating and Jquery of course.
I would greatly appreciate any input to help me make my final decision on what frameworks and libraries to use.
This is not a framework, but you may find Mozilla's Browser Quest implementation interesting. The whole thing is open source and they use HTML5 Canvas and Node.js (socket.io is a big player here) and it is entirely cross-platform
I'm working with a team on exactly this. Our research and experience suggests that a Node.js backend is definitely a good idea. What to use with Node.js? We've come up with two good possibilities:
Use websockets for communication and a front-end engine like Phaser for your rendering.
Use Isogenic Game Engine for everything.
(http://html5gameengine.com/ may help you to compare the feature-sets of the top HTML5 game engines including the ones I've just mentioned.)
I have been using Dojo and Dijit for more than a year to develop a browser-based IDE. Dojo is a great framework. But creating an IDE-like interface using Dojo is cumbersome and wastes a lot of time unless you are a CSS superman. I have a good understanding of HTML5, JavaScript, and CSS. Building the UI I needed required several CSS hacking that I found by trial and error. There was no systematic way to get from the UI design to the implementation and I am afraid to change the UI layout because any simple change can break the UI, mostly by adding irrelevant scroll-bars to Dijit panes where I do not need them. (the complex UI has 4-5 levels of nested panes including mostly border containers and content panes)
Recently I have come across SproutCore and Cappuccino, which have great demoes and their look and feel is more desktop-based. There has been several discussions comparing these two with each other. But none of them talk about how systematic and quick is it to get from UI design to implementation? Ideally, I should be able to implement the UI I want not more than a couple of days (Assuming that I know the framework), and changing them in the future should be easy.
The other difficulty with Dojo is that I have to work directly with DOM, to append and remove dijit widgets. While I do like to keep this flexibility, I wish I could use a higher level of abstraction to define the application UI. I have read about MVC in SproutCore and Cappuccino, but I am wondering if in practice the provided abstraction layer speeds up the UI development? or the provided layer is a fancy architecture that only increases the readability of the code? Will I lose the direct access to DOM if I build my UI using these abstractions?
Cheers,
Navid
Cappuccino is much higher-level. You write in Objective-J, not HTML/CSS/JavaScript. I personally do not recommend it as Objective-J is a niche language and you'd be stuck with something not widely-understood by everybody. You'll find it more difficult to look for answers to problems, and other people will have more difficulty in maintaining your code.
However, due to it being high level, it does shield you from the drudgery of programming in "standards" (i.e. HTML/CSS/JavaScript). Therefore, you should be able to develop UI's faster and easier, but you'll have to instead learn the ins-and-outs of Objective-J. All-in-all, not much to gain here, I suppose.
SproutCore, on the other hand, is HTML/CSS/JavaScript based, so you don't really have to relearn the basics. It follows the MVC model of separating UI and data concerns, so programming UI's should be easier.
My personal recommendation is to stick with Dojo -- 1.6 has come out, which has change-tracking, state-tracking and bining support. 1.7 is around the corner. The MVC module is improving fast. The next version, 2.0, will be quite awesome. It is being actively developed on, and so you won't be left behind.
Dojo can also be used with the Closure Compiler's Advanced Mode to make highly-compact, highly-optimized, fully-obfuscated builds for deployment. Other JavaScript-based frameworks are not as adaptable.
Cappuccino most definitely goes beyond just improving readability. If you don't want something to have a scrollbar in Cappuccino, don't give it one. That's pretty much the end of the story and one of the great advantages of using such a framework. In my experience, HTML and CSS is just an endless troubleshooting session. With Cappuccino things go where you say they should and stay there. And this is true across browsers as well (most of the time).
Furthermore you can, if you choose to, build your user interface using Interface Builder and Cappuccino's nib2cib utility. This makes it trivial both to initially lay out and to then later shuffle buttons and controls around.
Have you considered jQuery and the jQuery UI?
I'm a software developer, and I'm going onto a project now that involves implementing a website using ASP.NET (3.5 / 2008, using the Web Client Software Factory). I've been tasked at creating a UI / UX Design Document for the project, however I don't really know where to start.
I've been on one project in 3 years where there was a formal UI design document, which included layout and style guidelines/rules (e.g. the application has a header, navigation, etc., links must be colour A, buttons for positive actions must be on the right, etc. etc.). It was pretty useful in hindsight, I appreciated that someone went into that much effort too - even defining the CSS classes in the document. However, the doc was based on an existing application and conformed to the business' overall corporate identity.
The current project is a new project, which at the moment doesn't have clearly defined requirements (yes, I know... how do you design when there aren't many requirements... I digress). It is hard to know what functionality exactly will be needed. There are two different user types / personas, but no formal research will be performed on them for this document. Also, I'm not sure of the corporate identity, apart from that the business has some rules regarding use of their logo, which I'll only get further clarification on in a few days time.
So I'm slightly in the dark, throwing paint at a canvas, hoping I get a pretty picture at the end (if only I were Jackson Pollock).
What would you include in this document? It is aimed at the business (the client), as well as the developers. I can think of only the below:
Layout - header, footer, content, navigation
Styles - colour palette and styles of the different expected components
User Interactions - when a user performs an action and must wait they are notified by a modal dialog, validation is done using AJAX, navigation should be contextual, tasks should be performed with a minimum amount of clicking / navigation, etc. etc.
Has anyone got any experience in creating such a document, or any known, tried and tested process for UI design?
Thanks,
James
There' all sorts of elements that could be included in such a set of documentation:
visual style guidelines (colors, typefaces, sizes, icons, etc)
branding guidelines (corporate logos, colors, messaging, etc.)
copyrighting style guide (terminology, proper messaging, proper voice, etc.)
persona/demographic targetting
page layout guidelines
CSS guidelines/standards
JS guidelines/standards
use cases
accessibility issues
usability issues
example implementations
IA path flows
Wireframe components
etc.
I'd pick up this book if you can to give you a start on thinking about this:
http://www.amazon.com/Web-Anatomy-Interaction-Frameworks-ebook/dp/B002ZY5FCW/ref=sr_1_2?ie=UTF8&s=books&qid=1262983955&sr=8-2
Along with all the other obvious components of your planning document, it would be a good idea to sketch portions of the UI along with an accompanying narrative of the specific use cases illustrated.
I've had issues in the past when attempting to communicate UI ideas. It is often useful to make sketches of dialog boxes and sequences of actions. If those sketches look too "real", then there is a tendency for them to become the spec for the final product.
To mitigate this, I've been playing with Balsamiq Mockups. It has the nice property that it is an editable back of a napkin, and deliberately renders all objects and screen layouts with a hand-drawn feel. I like the results I've achieved with it for small, internal projects. I haven't (yet) had the chance to use it for a large project with many external stakeholders.
The Wikipedia article for Human Interface Guidlines has some great links that I was going to suggest. Some of them may have far more information than you require, but they should give you a good idea as to what types of things you should add.
I have always found Apple's guidelines very complete and useful, but they are definitely very complete and require a lot of reading.
UX documentation is a critical part of the UX design procedure. It functions as a connection, providing context to the product’s lifespan from the initial concept to the present iteration.
Good UX documentation is straightforward yet lean. It should be favorably attentive, actionable, and purposeful. UX documentation is a functional document of a product’s journey from the beginning to the current release. This documentation is important for several reasons:
Organizational memory
Onboarding & handovers
Single source of truth
Fosters better communication & collaboration
A valuable R&D and IP
We are deploying some small web apps.
UI design is quite hard if done right, so lacking resources, we are now looking for a simple way to bring the casual user up to speed (with our bad design ;)).
Are there jQuery plugins that could be used to create a demo? (fire events, move dialogs, etc. etc. ?)
Should we use a totally different approach?
I prefer to do mockups using something like balsamiq - that way the customer doesn't think it's further along than it actually is.