Archives for January 2016

A Users Hierarchy of Digital Needs

January 26, 2016 Leave a Comment

There is some great discussion in the community about the importance of User Experience compared to Developer Experience. Nolan Lawson added a fun analogy to the mix with his piece on composers and audiences, reiterating the fact that users don’t benefit directly from our naval gazing.

Of course, the story isn’t “UX vs. DX!”. It isn’t an outright war between the two, and in fact they can work well together. Unfortunately it is easy to get the balance in the force wrong.

Jake Archibald had another great post on the new streams API for the Web. One of his examples talked about flow control, and how this new capability allows the streams and the platform to work hand in glove:

Imagine we were using streams to download and display a video. If we can download and decode 200 frames of video per second, but only want to display 24 frames a second, we could end up with a huge backlog of decoded frames and run out of memory.

This is where flow control comes in. The stream that’s handling the rendering is pulling frames from the decoder stream 24 times a second. The decoder notices that it’s producing frames faster than they’re being read, and slows down. The network stream notices that it’s fetching data faster than it’s being read by the decoder, and slows the download.

I content that we may have a backlog issue where the communities focus may not be in flow with the platform.

The Hierarchy Of Needs

Back to the diagram above. Here are the pieces of the pyramid and how they fit together in my mind.

Something Worth Doing

First of all, we should be building something that users need or want to do. This doesn’t mean that it has to cure disease, or only be something of social good, it just means that people see a use. Most startups fail because the timing of this use, a lack of marketing it, or the product not being good enough (see below) causes the rest to be moot.

This is the base. Few want to waste time building something that no one cares about. We want to solve problems and should focus here first.

Is Our Platform Capable

I would love to teleport anywhere in the world. Currently we don’t have a platform that supports that however. We next need to map the problems that we see into a solution that can actually work for our users today (ignoring R&D and academia).

We also need to work with our platforms to help prioritize the capabilities of the future. As their consumers, we need to help inform them as they may not be consumers themselves. This is an example of flow control.

If the platform builds features that aren’t used then there is a bad backlog.
If the platform doesn’t build features fast enough then we are left to our own devices, which could mean idle hands or leaving the platform.

I believe that one reason that we get a lot of DX tinkering in a community is when the platform isn’t keeping up. There are other reasons for this too however:

We are in an experimental phase where we have new capabilities that we are pushing and stretching
Productivity is a bottleneck (see below)

Can Our Users Actually Do It

Now we have the capability for a solution, can we design something that works for real humans. This is where the user experience kicks in to gear. It doesn’t matter if your platform has amazing capabilities if they aren’t wired up in a way that makes them usable.

Can It Perform Well Enough For Them To Keep Doing It

Performance builds from here and has strong ties to the usability and capabilities pieces below. Performance can make or break you. It is often the bottleneck, for example: OCR, VR, speech recognition, AI, etc. We have envisioned how computers could help us in some many places where we have needed R&D across many vectors to make them usable and performant.

Can Developers Fix and Iterate

If we can in theory build a great performing user experience, we then need to make it work in practice. It needs to not take a life time to build features. We need to be able to debug and fix issues in short order. You shouldn’t need to be an enlightened guru to be able to eek out the performance out of the platform, there should be a clear well trodden path.

You can see how all of these fit together and are important. What is the bottleneck for what you are trying to build? It may vary.

We need to work the flywheel across all of these, and when we do so great things happen. Our mobile users have new needs that we need to solve. We need to build offline first experiences that perform well for them and allow them to get their tasks done. We need to have developer ergonomics that allow developers to easily build out these features and keep iterating to solve more problems.

From problems to solution ideas to platform capabilities to user experience to developer experience. We walk up and down the stack all day. One learns from the other. The more we can do to get a reactive well oiled machine, the more we can get done.

This is why I think it isn’t UX vs. DX. This is why I think we need to work together better than ever. Our users are counting on us to do so.

What can we learn from how jQuery symbiotically pushed the Web Platform forward?

January 24, 2016 Leave a Comment

When Ajax happened we had popular frameworks in Prototype, Dojo, and MooTools, but it was jQuery that took over and went to the next level in popularity and usage.

Since then we have moved through eras of sprinkling in some JavaScript to a web page, to larger frameworks to enable SPAs: Backbone, Angular, and the current darling: React.

As we reflect on the popularity of React, it is important to think about “why”, but also how we can bake the good ideas into the platform.

There are elements of React as the current dominant ecosystem (there are always many, and due to the growth of the Web some of the smaller ones are naturally in more usage than the winners of the past!) that remind me of the jQuery era, but there are also important differences to reflect on.

What does jQuery teach us?

One of the great things about jQuery was that it had a simple, powerful idea. It’s entire mindset was “find these items in the DOM, and attach these events to them”. Others had this too, but they were often secondary. Prototype (a big favorite of mine back then) had $ to get an element, and $$ was for selecting.

The fluent API made for a very functional way of working on these elements and events. You didn’t have to create loops over elements all of the time, and it resulted in very clean code for the majority use case (not as much fun if you wanted to do the opposite).

This was all simple enough that “web designers” could easily get up to speed and sprinkle away functionality.

A plugin ecosystem exploded as everyone contorted to reinvent, or just wrap prior scripts into this style. Come up with something you want to do on the selection and add it to the jQuery prototype and you are good to go!

While the simplicity of the ecosystem was fantastic, the community quickly ran into the age old problem of curation. There was just so much duplication and cruft to sift through. It also fakes you out to think that you are building out a lot more than you are. You could add functions that understand The One True Pattern, but there wasn’t a component system that you could build on (unless you picked one of several).

The best part of this era though was how the benefits were embraced by the platform. John Resig didn’t try to build The jQuery Platform, even though plenty of VC’s pushed him to. Instead he helped browsers and we now have items such as querySelector*, dataset, and classList. Once you bake these type of things in, your library becomes a place to hold your opinions, and make the cross browser stuff work (polyfill, prollyfil, and ugly hacks to boot).

I also think that there were plenty of other good side effects. The fluent style of API probably opened peoples minds up in a way that only helped us with promises and rethinking APIs such as XHR vs. fetch.

How is it different with React?

All in all jQuery has evolved along with the Web platform, helping improve things beyond itself.

I think that there is an opportunity to do the same with React, but I am concerned that we could also go in another direction. React came out running in the same way that jQuery did. jQuery was later to the game and ran past Prototype, Dojo, MooTools, and many others. React has done the same to Backbone, Angular, and others.

If you look at the details you can get frustrated as they are not apples to apples. React is a lightweight view layer, not an application framework or platform! These days React is more than its roots, and often refers to all of the pieces that have come out around the edge: Redux et al. Now a days if you walk up to someone at a conference and say “I use React” it is akin to “I use C++”. You then have to explain how you use it: “Oh, I use boost and …” => “Babel, Redux, react-router, ….”.

There is a lot to love about React. I really enjoy the developer experience, mainly the ability to tie together a functional declarative mapping of “given this state, what do I render?” This is so very powerful, and feels like you are back to the world of reloading page. This empowers you to reason through your application, write tests that make sense, and debug the application.

Debugability is hugely important, and I think we may not give it the importance that it deserves. Just ask the Circle CI team how important it is to them to be able to take some application state from a user and replay it to see what was going on? How amazing it is to be able to snapshot the state and get undo/redo in a much saner manner? Game developers have always understood this… you can dump your game state and restart right where you are.

Early on in the React hype cycle we heard that the biggest pro was performance, which in my view was very much missing the mark. Many developers picked it up despite the fact that they didn’t like that ugly JSX thing because they heard it was so fast. Over time they found that the componentization approach was sound and sane, which I think bodes well for us to look at Web Components as they launch cross browser this year, and they loved the flow of the functional data model to the view.

It is pretty obvious that you can think of scenarios where diffing two trees won’t be as fast as mutating some state in the DOM. You can also think of scenarios where you wouldn’t want to make multiple changes to the same parts of the DOM to cause jank and rerendering for no reason. It depends. The DOM used to be so very very slow that you would very much want to make sure that you don’t touch it until you really needed too, but we have also seen that these days the DOM may not be as slow as you think, and React may not be as fast as you think.

What would the real win be? Wouldn’t it be great to let the browser handle more of the load, but let the developer declare the state? That is the world that I would love to strive for, and it requires getting the browsers and web devs together again.

Mobile

There has been another huge change between when jQuery happened and when React happened: mobile.

Not only do we need to think offline first, and progressively add on capabilities based on what the user agent can do, but we need to start from the understanding that the network is flaky, and the devices are amazing (ignoring many of the crappy ones out there, and the problem is that we can’t ignore them as your current users and next billion users have them) but under powered compared to our desktop counter parts.

We need to push the Web platform to run fantastically well on mobile, and we are getting there… it just requires a push to work together.

React Native showcases the other change. jQuery was pushing to make web development easier on the Web (jQuery Mobile came later and was still more mWeb than WebView IMO). These days developers that are looking to get their services out to their users need to seriously consider iOS, Android, and the Web. The balance of these changes depending on what you are building, for who you are building it, and where they are located (US == iPhone++, India == Android++).

If you take a large development shop, chances are a large percentage of them are web developers. Also, no one really WANTS to minimize their leverage between their iOS, Android, and Web applications. This is where developers will always push to get more leverage, even if it ends in roads that can’t deliver an experience that is top class.

React Native is an example of this, a push to see if we can get more leverage, and it is a huge change from the world of jQuery. At this point the “platform” is React (a la Angular etc) vs. the Web or iOS or Android. To do a great job you need to understand the true computing platform, but this aims to allow you to do more across them. This is where we can get at odds with the Web and try to fight it.

I understand this fight. I begrudgingly switched Bespin to run on <canvas> to deliver the experience that we wanted, but it meant that we lost out on much of the Web (accessibility etc).

I see the same problems occur. Just do a search for content editable and React and you will see similar struggles, which show the fight between React wanted to control the world and the browser having the control.

There is often a fight for control between user space and kernel space. This came to mind again when reading Bryan’s post on unikernels and his case that shows that not only isn’t it more performant, nor secure, but that it never can be. You give up too much by shoving everything into a single purpose kernel, including the debugability point, echoing its importance.

In 2016 I want to find a way to bring a fantastic blend of debugability, developer experience, and performance to the Web and developers all over. We can take lessons from the best routers, data abstractions, and component models. We can build new primitives into the Web platform that will enable not just one framework speed up but all of them.

As we work for a Web that performs up to snuff for users, we need to pull together. Can we pull it off? Can we speed up React and friends now as we evolve together for the future? Or is the Web destined to be a second class citizen?

What is your guiding doctrine?

January 20, 2016 Leave a Comment

I really enjoyed DHH’s articulation of the Rails Doctrine. He does a fantastic job of reflecting and clearly explaining where he stands on issues.

I savored the entire piece, thinking about where I may agree or disagree. By going up a level, as this piece does, to articulate the 8 pillars, resets the mission in some ways.

Rails was born in a time where many of us were building CRUD web applications. I fell in love with it in a similar way to DHH, in that ruby fit my brain. I care about the nuances and being able to choose my language. I enjoy the poetry of code, and Java was never a love, but rather felt like a language for the masses (which has a lot of pros, but didn’t fit my preferences).

Fast forward to today and we are thinking about all of the platforms and reach that we can get to our users. We are thinking about services, and although I share the disdain to premature-micro-servicification, we often serve multiple clients and need to cater to that world.

Rails can work well in this new world, but the price of the opinions don’t pay off as much as it may have back then. Other options have improved, and there are more choices to be made (messaging, database options, etc).

Art and Service

The other item that jumped out from the piece was the talk about art and its intrinsic importance. It is framed that building something to get a job done is beneath the art. This is where I disagree the strongest.

“It was the event that marked my own personal transition from ‘doing programming because I needed programs’ to ‘doing programming because I fell in love with it as a mode of intellectual exercise and expression’.” — DHH

I think that it can be a privilege to serve, and service can include building a tool or something of use for your users and even your business.

DHH can argue that this will happen naturally, and that the best work comes out of the art, but I am not sure that this is always the right correlation.

It is perfectly noble to be focused on how best to make your users awesome, and make choices that could even go against The Art and certain purity. You are constantly working within trade offs. Performance is a great example here. I think that we often prematurely optimize and the developer experience can take a hit. However, we should be striving for the best user experience even if we have to do some ugly hacks to make that work. Ideally we can put those hacks in a box so that most don’t have to see it, but it is OK, albeit not ideal, for it to be there.

Earlier in my career I was more focused on the technology, for technologies sake. As time went on I have gotten closer to “what am I doing for my users” and I think a user-centric approach is a great one.

Rails itself is very very user (developer) centric, I just want to make the point that ‘doing programs because I want to impact X’ isn’t lesser.

Thanks again, @DHH, for not only giving us a fantastic toolbox, but laying out a higher story. I know that the post is one that I will revisit and reflect on in the future, and it will cause me to ask myself… what is my guiding doctrine for X?