Visualisation, HTML5, UX and HTTP links

modeling-languages.com: 10 JavaScript libraries to draw your own diagrams

Comparative table of JavaScript drawing libraries

To finish here is a basic comparative table between the presented libraries.

Library	License	Language / infrastructure	high/low level	built-in editor	Github (04/02/2015)
JointJS	MPL	HTML Javascript SVG	high	No	1388 stars 265 forks
Rappid	Commercial 1 500,00 €	HTML Javascript SVG	high	Yes
Mxgraph	Commercial 4300.00 €	HTML Javascript SVG	high	Yes
GoJS	Commercial $1,350.00	HTML Canvas Javascript	High	Yes
Raphael	MIT	HTML Javascript SVG	low	No	7105 stars 1078 forks
Draw2D	GPL2 commercial	HTML Javascript SVG	medium	No
D3	BSD	HTML Javascript SVG	low	No	36218 stars 9142 forks
FabricJS	MIT	HTML Canvas javasript	low	No	4127 stars 705 forks
paperJS	MIT	HTML Canvas javascript	low	No	4887 stars 496 forks
JsPlumb	MIT/GPL2	HTML Javascript	medium	No	2161 stars 563 forks

The best UI is no UI

In the modern Linux community, people have a little more clue about UX. There’s still a (nicer) screen like this buried somewhere. However, I never use it. The main UX is that if you plug in a network cable, the computer connects to the network. There’s no need to open a window or click any widgets at all.

Most of the work to implement “the computer connects automatically” was behind the scenes; it was backend work, not UI work.

The App-ocalypse: Can Web standards make mobile apps obsolete?


Making Netflix.com Faster : Universal Javascript


The Top UX Predictions for 2015

Engineers don't let engineers design user interfaces. pic.twitter.com/XKSDUOxKHe
— John Bellomy (@cowbs) September 28, 2014

Why facebook switched from HTML5 to Native


Good HTML5 links:

http://diveintohtml5.info/

http://caniuse.com/

http://trends.builtwith.com/

http://html5rocks.com

http://builtwith.com/

http://oldbrowsers.com/

https://modern.ie/en-us

http://html5boilerplate.com/

http://html5boilerplate.com/

http://www.javascriptsource.com/

http://www.javascriptkit.com/

http://jsfiddle.net/   metrics on JS code

http://jsperf.com/  metrics on JS code

http://htmldog.com/guides/css/

http://www.cssplay.co.uk/

https://developer.mozilla.org/en-US/    SPECS

http://devdocs.io        developer docs



UX is not UI

So how do we get to implementing a killer UI? Let’s take a journey through an ideal hypothetical:

1. We presume the problem has been identified through the user/market/persona research.
2. User flows and stories are made, then trashed, then made again, then iterated on until the problem flow is clear.
3. With an idea of ways to solve the problem, some rapid experiments are carried out to validate the assumptions with the personas.
4. Some IA work is done to break out the product/site into the logical areas and hierarchies.
5. Various wireframes and sketches are drawn to start to organize where things could go on the screen.
6. With all the preceding research material and UX work, now mockups with UI included can be made with confidence.
7. With mockups and a UI designed, they are user tested and iterated on through some prototypes or experiments.
8. After the mockups have been vetted, it’s now time to code up the interface – UI Design!
9. Once the usability of the UI has been honed, you can move it on to production – the place that people usually think of as the singular UI.

That’s quite an idealized journey. Not every step has to be taken depending on time and resources. There’s also nothing to stop it from going pretty fast; a matter of days even. I’ve designed countless UIs straight from my head to the screen without following those steps, but that’s not UX. I believe they call it “design malpractice.” Good UI is not trivial or simple – solid UX, killer visuals, and effective interaction are all part of the formula.

Is it time to go SPA only?

We have all witnessed the “slow SPA effect” though. You know the one. After tapping a link the page goes from white to show some app UI, but then you are watching a custom spinner as it goes back to the server to get the real data. Irritating.
SPA doesn’t have to be this way though. Google+ was one of the first web apps that I saw that would send the data required along with the app for first load, and we can do the same on our SPAs. This way, the app is able to render itself right away vs. having to phone home an extra time.
Is this as fast as sending down the right HTML (and then co-opting it and taking over)? No. Is it the bottle neck to your performance? I doubt it. Add to this the fact that you can also go after localStorage and friends, you may have a bunch of data already.
When you get to the point where it is important to tweak every part of your performance stack (e.g. customer HTTP client and servers!) you will want to look at each interaction and think about:

• What is important to show immediately?

• What can we lazily load?

• What should start low-res and then have us flip to high-res?

• What can be cached?

WebSockets, caution required!



Google PageSpeed tools

PageSpeed Rules

• Avoid landing page redirects
• Enable compression
• Improve server response time
• Leverage browser caching
• Minify resources
• Optimize images
• Optimize CSS Delivery
• Prioritize visible content
• Remove render-blocking JavaScript
• Use asynchronous scrip
•