Open Stack

We have been having this discussion here on the mailing list [1][2] and also in the Horizon team meetings [3].

The overall consensus has been that we are going to move forward with a JavaScript requirement.

Most of the pushback to support non-JavaScript is based on web-accessibility standards last updated in ~2007.  This pseudo-requirement stemmed from incomplete/varied support of JavaScript in browsers and the lack of support for technologies like screen readers for JavaScript. These generally do not hold true any longer.  Additionally, no one has responded to any of the mailing list items to advocate maintaining the non-JavaScript use cases.

In an effort to create a better user experience for users, we have chosen to take an approach to require JavaScript.  This means that key areas of functionality can now require JavaScript. Horizon is not just a reference implementation, it is a  full working UI for OpenStack.  We want the best user experience we can provide. So, we will incorporate JavaScript while maintaining accessibility for tools like screen readers.

OpenStack is a community using python for most code, barring some exceptions.  We are not moving away from that.  This is not a wholesale replacement of the server backend to allow an almost entirely client side application.  This is a move to add JavaScript in targeted interaction points to improve user experience.  Today, JavaScript is already sprinkled throughout the code.  I am not entirely sure what use cases still support a non-JavaScript fallback.  So, my feeling is that this past soft-requirement is already broken.  And supporting a separate code path for non-JavaScript fallbacks without rigorous testing is prone to fall apart.  Today we do not have automated testing for the non-JavaScript tasks. 

New project teams often contribute the first implementation of the UI for their project to Horizon.  Our goal is to still support this path without requiring JavaScript expertise, or to write any JavaScript at all.  If later, a user experience can be improved with some targeted JavaScript, that work will be done by someone that has those skills, and reviewed by individuals that understand JavaScript and the associated libraries.

So the discussion before us now is: what tools do we use to best write/maintain/test the JavaScript we are adding.  There is pushback against node.js by the distros for reasons also documented on this mailing list.  There seem to be alternatives that we are tracking down.  But writing consistent, maintainable and testable JavaScript is the priority.

Additionally, for anyone still requiring a non-JavaScript enabled path to manage an OpenStack implementation, the CLIs work wonderfully for that.

-David Lyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/018629.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2013-November/019894.html
[3] http://eavesdrop.openstack.org/meetings/horizon/

> -----Original Message-----
> From: Radomir Dopieralski [mailto:openstack at sheep.art.pl]
> Sent: Monday, November 25, 2013 9:32 AM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [horizon] JavaScript use policy
> 
> Hello everyone,
> 
> there has been some talks about this behind the stage for a while, but I
> think that we need to have this discussion here at last and make a
> deicsion. We need a clear, concrete and enforcable policy about the use
> of client-side JavaScript in Horizon. The current guideline "it would be
> nice if it worked without JavaScript" doesn't really cut it, and due to
> it not being enforced, it's really uneven across the project.
> 
> This is going to be a difficult discussion, and it's likely to get very
> emotional. There are different groups of users and developers with
> different tasks and needs, and it may be hard to get everyone to agree
> on a single option. But I believe it will be beneficial for the project
> in the long run to have a clear policy on this.
> 
> As I see it, we have basically three options about it. The two extreme
> approaches are the simplest: either require everything to work without
> JavaScript, or simply refuse to work with JavaScript disabled. The third
> option is in reality more like another three hundred options, because it
> would basically specify what absolutely has to work without JavaScript,
> and what is allowed to break. Personally I have no opinion about what
> would be best, but I do have a number of questions that I would like you
> to consider:
> 
> 1. Are the users of Horizon likely to be in a situation, where they need
> to use JavaScript-less browser and it's not more convenient to use the
> command-line tools?
> 
> 2. Are there users of Horizon who, for whatever reason (security,
> disability, weak hardware), prefer to use a browser with JavaScript
> disabled?
> 
> 3. Designing for the web constrains the designs in certain ways. Are
> those constrains hurting us so much? Do you know any examples in Horizon
> right now that could be redesigned if we dropped the non-JavaScript
> requirements?
> 
> 4. Some features are not as important as others. Some of them are nice
> to have, but not really necessary. Can you think about any parts of the
> Horizon user interface that are not really necessary without JavaScript?
> Do they have something in common?
> 
> 5. Some features are absolutely necessary, even if we had to write a
> separate fallback view or render some things on the server side to
> support them without JavaScript. Can you think of any in Horizon right now?
> 
> 6. How much more work it is to test if your code works without
> JavaScript? Is it easier or harder to debug when something goes wrong?
> Is it easier or harder to expand or modify existing code?
> 
> 7. How would you test if the code conforms to the policy? Do you think
> it could be at least partially automated? How could we enforce the
> policy better?
> 
> 8. How much more experience and knowledge is needed to create web
> pages
> that have proper graceful degradation? Is that a common skill? Is that
> skill worth having?
> 
> 9. How much more work are we ready to put into supporting
> JavaScript-less browsers? Is that effort that could be spent on
> something else, or would it waste anyways?
> 
> 10. How much do we need real-time updates on the web pages? What do
> we
> replace them with when no js is available -- static and outdated data,
> or not display that information at all?
> 
> 11. If we revisit this policy next year, and decide that JavaScript can
> be a requirement after all, how much work would have been wasted?
> 
> 12. Are we likely to have completely different designs if we require
> JavaScript? Is that a good or a bad thing?
> 
> 13. Can we use any additional libraries, tools or techniques if we
> decide to require JavaScript? Are they really useful, are are they just
> toys?
> 
> 14. How do we decide which features absolutely need to work without
> JavaScript, and which can break?
> 
> 15. Should we display a warning to the user when JavaScript is disabled?
> Maybe be should do something else? If so, what?
> 
> 16. If JavaScript is optional, would you create a single view and
> enhance it with JavaScript, or would you rather create a separate
> fallback view? What are the pros and cons of both approaches? How would
> you test them?
> 
> 17. If we make JavaScript easier to use in Horizon, will it lead to it
> being used in unnecessary places and causing bloat? If so, what can be
> done to prevent that?
> 
> 18. Will accessibility be worse? Can it be improved by using good
> practices? What would be needed for that to happen?
> 
> You don't have to answer those questions -- they are just examples of
> the problems that we have to consider. Please think about it. There is
> no single best answer, but I'm sure we can create a policy that will
> make Horizon better in the long run.
> 
> Thank you,
> --
> Radomir Dopieralski
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev