Creating a web user interface

[NickFitz]

Bootstrap can result in a rather samey appearance for sites that use it, but the only people who give a tulip about that are graphic designers; a degree of familiarity is a good thing for real users, who are trying to actually get things done rather than marvel over the colours, fonts, and spacing. As long as the limitations it imposes don't interfere with your artistic vision, use it and save yourself a load of time.

Jquery is really quite easy to pick up, as it's just a bunch of library routines hiding browser differences. Given that you don't have to worry about older browser support you should go straight for the 2.x branch, which eliminates a lot of leftover cruft.

As far as particular UI components are concerned, there are an absolute shedload of free Jquery plugins, of varying quality: the good ones do tend to rise to the top, and aren't hard to find, as long as you don't always just download the first result in a Google search

Avoid Angular.js like the plague. Imagine somebody read the whole of Design Patterns and Patterns of Enterprise Application Architecture, understood less than 1% of them (but thought they understood it all), then read the documentation for the most over-engineered, bloated app framework ever created and understood less than 1% of that, then took the knowledge they'd acquired and misapplied it in the worst possible way to a context for which it was utterly unsuited: they'd produce Angular.js; except it's worse than that.

For going the SPA (single-page app) route, it's probably worth jumping in with Backbone.js. It can appear a little daunting at first sight, but it's solid underneath and gives you a lot of good stuff that you won't manage otherwise, life being too short (literally, in your case).

So to summarise:

1. Use Bootstrap to get your UI layout in place;
   
   
2. Chuck Jquery 2.x in there;
   
   
3. Identify suitable Jquery plugins for any particular widgets that aren't already in Bootstrap - you can, of course, limit yourself to components written specifically for Bootstrap, which will make integrating them easier;
   
   
4. Chuck Backbone.js (and its one dependency, Underscore.js) in there;
   
   
5. Start creating the Backbone Models and Views, and the Router that connects them to the back end via HTTP.

Then just keep going until you're done; I'm sure you know how to do that bit

There are a lot of worthwhile Backbone tutorials out there, as well as a lot of crap ones. A good place to start is Jeremy Ashkenas's list, as he created Backbone.js so he's a pretty good judge of them

EDIT: oh, one more thing: don't get hung up on the back end. Remember, as far as a client running in a browser is concerned, everything on the server is just stuff accessed over HTTP. It has a URL, which can accept certain request methods (GET, POST, etc.), and maybe parameters (e.g. GET http://banana.example.com/bunches/?ripeness=medium to get a list of all bunches of bananas of medium ripeness), and which returns a status (e.g. 404 Not Found if there are no medium-ripe bunches, 200 OK if there are) and a response body (an HTML page saying "Yes, we have no medium-ripe bananas", a JSON response containing an array of bunch IDs). That's all the client knows, and all the client needs to know. It could be implemented in PHP, or Struts, or node.js, or you could have a bunch of North Koreans sitting at Teletypes sending back responses; it doesn't matter.

[doodab]

Avoid Angular.js like the plague. Imagine somebody read the whole of Design Patterns and Patterns of Enterprise Application Architecture, understood less than 1% of them (but thought they understood it all), then read the documentation for the most over-engineered, bloated app framework ever created and understood less than 1% of that, then took the knowledge they'd acquired and misapplied it in the worst possible way to a context for which it was utterly unsuited: they'd produce Angular.js; except it's worse than that.

You aren't a fan then?

With so many recommendations for bootstrap I will deffo give it a go. The layout is super simple and only took me a few hours (+ book reading time) in CSS when I originally did it so I expect it will be fairly easy to duplicate.

[doodab]

EDIT: oh, one more thing: don't get hung up on the back end. Remember, as far as a client running in a browser is concerned, everything on the server is just stuff accessed over HTTP. It has a URL, which can accept certain request methods (GET, POST, etc.), and maybe parameters (e.g. GET http://banana.example.com/bunches/?ripeness=medium to get a list of all bunches of bananas of medium ripeness), and which returns a status (e.g. 404 Not Found if there are no medium-ripe bunches, 200 OK if there are) and a response body (an HTML page saying "Yes, we have no medium-ripe bananas", a JSON response containing an array of bunch IDs). That's all the client knows, and all the client needs to know. It could be implemented in PHP, or Struts, or node.js, or you could have a bunch of North Koreans sitting at Teletypes sending back responses; it doesn't matter.

I know all about the the back end, although usually serving XML web services. That's actually what the product itself does, among other things, which is why that side of the equation is set in stone. We're using an existing OSGi runtime that supports JEE web apps so that's what we need to deploy. This module is just the configuration UI for the product, so only used by administrative users. The product itself runs alongside another product which provides a Java API, it also needs to be deployable into the customers choice of JEE runtime if need be, so rebuilding the entire product on some other web app framework isn't an option, hence my earlier comment.

Regarding the API module, that's going to be a java facade object so if we go down the route of a client side web app exchanging JSON or XML with the server we'll need another layer in there to do the translation. Of course that could be implemented using spring MVC, but as it stands the server side controller will just grab that object and manipulate it directly so it's a little simpler for a PoC.

[Jaws]

I've been using KnockoutJS recently and in the past and it has produced decent results although I can't comment on the performance if you have absolutely loads of elements on your page because that wasn't the design.

For server side I have generally used MVC (ASP.NET) which is fine due to the way you can easily set up action methods to return and receive data as json (presumably it is the same with spring). I dont think it matters too much what you use on the server end as long as it can easily deal with json data. Having json should be far simpler than working with xml client side. I gather there are libraries to get around it now but I remember there being quite a few differences between IE/mozilla etc on XML.

I agree with all the recommendations for bootstrap / jquery. Very easy to set something up that's good looking via bootstrap starting with one of the templates on their site.

[NickFitz]

I know all about the the back end, although usually serving XML web services. That's actually what the product itself does, among other things, which is why that side of the equation is set in stone.

It's worth bearing in mind that Jquery handles XML via HTTP very well. For example, the XML document

<foo>
    <bar type="grue">Eaten</bar>
    <bar type="not-grue">Not eaten</bar>
</foo>

can be loaded asynchronously and then queried for specific items of data using Jquery:

$.ajax("/foo.xml").done(function(xml) {
    var xmlDoc = $(xml),
        grues = xmlDoc.find("bar[type=grue]");
    alert(grues.text());
});

which means you can get very quickly from the low-level shenanigans of querying a remote XML data source to the high-level business of updating your models and/or views with the data.

[NickFitz]

I've been using KnockoutJS recently and in the past and it has produced decent results although I can't comment on the performance if you have absolutely loads of elements on your page because that wasn't the design.

For server side I have generally used MVC (ASP.NET) which is fine due to the way you can easily set up action methods to return and receive data as json (presumably it is the same with spring). I dont think it matters too much what you use on the server end as long as it can easily deal with json data. Having json should be far simpler than working with xml client side. I gather there are libraries to get around it now but I remember there being quite a few differences between IE/mozilla etc on XML.

I agree with all the recommendations for bootstrap / jquery. Very easy to set something up that's good looking via bootstrap starting with one of the templates on their site.

I used Knockout.js at a client last year. It's generally excellent, in my view, but you're right about the potential for performance issues. I was dealing with a grid (an HTML table under the covers) with potentially dozens of columns and thousands of rows, for the UI for an application used by commodities traders. (It also had little tricks like real-time updating of individual cells, but that's another story.) I was able to get the necessary performance out of Knockout.js, but only by diving deep and writing my own custom bindings for various things.

But it's certainly worth a look as an alternative to Backbone.js.

[minestrone]

If you get bootstrap I would the build tool on the site Customize and download · Bootstrap and change the fonts straight off, the default ones look terrible. I use open sans mostly...

@font-family-sans-serif

'open sans', arial, sans-serif


@headings-font-family

'open sans', arial, sans-serif

...but anything other than the ones that come with the regular download. As has been said there are a lot of bootstrap sites that look identical and just that change loses the samey aspect to your site.

[doodab]

Ok, it seems that if I go down the backbone / single page route i'm just shipping data to and from the server as json using ajax so I don't need to worry about forms per se. Is it sensible to be looking at form tags to build the views or should I be using other widgets? Probably need to.read through their docs a bit more and look at the examples....

[NickFitz]

Ok, it seems that if I go down the backbone / single page route i'm just shipping data to and from the server as json using ajax so I don't need to worry about forms per se. Is it sensible to be looking at form tags to build the views or should I be using other widgets? Probably need to.read through their docs a bit more and look at the examples....

Yes, use forms: apart from anything else, they have accessibility value.

My approach is usually to bind the view to the related form, then use the form's submit event to do the magic. Apart from all the other conveniences that flow from this, it means you keep native browser behaviour such as a form being submitted when the user hits Enter while in a text field. (It's surprisingly common for sites to break this, and it always fills me with deep contempt for their developers. Even more idiotic are the ones that break it, then try to patch it with key event handlers, when all they have to do is add the form tags and the browser will do the work for them.)

For example, the site I'm currently working on for ClientCo has both registration and login forms on the home page when the user isn't logged in, or meaningful content and a form for the actual purpose of the site when they are logged in.

The initial content is decided on the server (though I may have to switch to loading that on page load on Tuesday), but both registration and login are done via Ajax, and the LoginView and RegistrationView are then replaced by the informative content (non-interactive, so no need to worry about it) and the form. So assuming a logged out user, I have something along the lines of:

    <form id="login" method="POST" action="/login/">
    …
    </form>
    <form id="register" method="POST" action="/register/">
    …
    </form>

and then define a LoginView and a RegisterView - I'll just show a rough skeleton of the first:

ClientCo.views.LoginView = Backbone.View.extend({
    el: "#login",

    doMagicalLoginStuff: function(evt) {
        // things are done in here...
    },

    events: {
        "submit #login": "doMagicalLoginStuff"
    }
});

Then, when the user logs in or registers successfully, the relevant view can just update the model accordingly, and other views can respond accordingly; for example, by rendering themselves.

The point is that, if I didn't have those forms to bind to, I'd have to take care of things like checking if they've hit Enter rather than clicking the submit button, and a bunch of other things associated with forms.

Also, a user of assistive technology (such as a blind user with a screen reader) will find that their software understands the form, and switches into the special mode such tools have for dealing with forms; and when they submit it, the JavaScript will correctly handle that. In fact, they may not even realise that anything other than the normal browser behaviour was going on. If you don't use forms, that simply can't work, and you've potentially put your client on the wrong side of disability discrimination legislation.

[doodab]

Well thanks for all the help. I've nearly got a basic layout together using HTML5 and bootstrap though I need to do a bit of work on the styles and colours and so on.