Building solid UI takes time.
Building nice looking, well designed interactive UI for the web is difficult to do both well and with speed. As the web grows, people expect more and more complex interactive experiences. As those who build it, we need to find a way to simplify the process of constructing complex webapps with solid user experience.
In recently speaking with a colleague, who had built a 'movie-search' demo webapp in AngularJS, we started to discuss the development process, with a focus on speed and efficiency. He stated that there was a self estimated 4-5 hours worth of work in constructing the app (starting from an empty repository). The app consisted of:
The foundation of the UI was generated by an AngularJS + Bootstrap boilerplate, which provided a basic app with routing, a toolbar and a head-start in styling. Following this initial boilerplate, a substantial amount of the time involved in the initial app, was creating the custom 'directives' that would display both the search results and the detail of a movie.
This resulted in two distinct directives/pages. A search directive with an input field and a list of resultant items, that would be dynamically populated as the value of the input field changes. For this simple task, we need at the minimum - an observer function for the 'onchange' event of the input, a simple HTTP request, some UI for displaying each item, UI repetition code and binding to the JSON parsed array of results.
For the movie details page, things are similarly complex. We would need some markup for the UI layout of the page, a HTTP request, some client-side routing to select the title from the URL and to parse and bind the response into state.
Of course, you could probably build a similar app in the same stack in a quicker manner. But, the focus of this is to try and shift thinking away from technology and get back to basics. If we want to be fast, we should only be writing the bare minimum.
For what is a fairly basic app, using live API's, start to finish in 4-5 hours seemed good. Though, we both agreed that this time could be reduced by a shift in how we developed. Whilst the boilerplate gave a starting point, there was a large amount of work required to build the remaining UI, trigger updates on search term change and handle API responses. If we could reduce the amount of custom UI and logic that needed to be written, we could save a lot of time and focus on writing the unique parts of the app, rather than re-writing some boilerplate code for lists, http requests .etc.
I felt that encouraging reuse, not writing code I didn't need to and taking advantage of the community to save time and effort unnecessarily would allow you to save time and build faster. Why re-invent the wheel?
For this, Web Components are ideal. webcomponents.org defines Web Components as:
For improving development (speed especially) this has a few major benefits.
Whilst we could just dive in and use the base API, I chose to use a library to fill in some of the boilerplate code I'd need to write otherwise. For this I chose Polymer.
The Polymer library provides a set of features for creating custom elements. These features are designed to make it easier and faster to make custom elements that work like standard DOM elements.
Again, these aren't unique to Polymer! However, my primary reason for choosing Polymer is the rich library of first and third party components available. If we're going to be fast, we need all the help we can get!
At this point I had my technology decisions made, the design decided . I felt that I was ready to start actually constructing the webapp. Last Friday at the end of the day, I found 30 mins of free time and decided to start the clock.
Beginning with no repository, I started the clock/screen capture and started to create the skeleton of the app. I used the basic application starter from Polymer App Toolbox which provided the initial polymer dependencies and a starter component. I added some 3rd party web-components from the component registry for thing such as routing, http requests, dynamic lists and various other UI.
Chaining these components together allowed me to get to a point of having data appear dynamically from the search API in a very short space of time and overall finishing the app in just about 30 minutes.
A timelapse of this process is available below - in addition to the raw video!
So. The app itself?
(Dynamic movie search page, populated as you enter the search term)
These two screenshots show both of the core UI pages that were necessary. Above is the dynamic search page, with a search-field that automatically calls an API on change - populating the search results with the data that comes back.
(Movie Detail page)
In addition, the second page (movie-detail) shows me a display of the core information retrieved from the movie detail API. It takes advantage of a Web Component for URL routing to retrieve the movie title from the URL and perform the API call.
In the process of building this app, I installed and imported ~ 10 Web Components. For everything from routing to handling AJAX requests, to drawing styled UI with minimal fuss.
Rather than list all of the components I used here, I'd highly recommend you install the Polymer Ready Chrome Extension. It's a really cool tool that can show you exactly what Polymer Web Components are used on a page, and if you hover, it should show you where on the page it's used.
You can find the movie search app here:
Polymer Movie Search code is available on GitHub:
Angular Movie Search code is also available:
And you can find the Angular Movie Search app here:
Finally, full real-time screencap: