Please note: This schedule is for OpenStack Active Technical Contributors participating in the Icehouse Design Summit sessions in Hong Kong. These are working sessions to determine the roadmap of the Icehouse release and make decisions across the project. To see the full OpenStack Summit schedule, including presentations, panels and workshops, go to http://openstacksummitnovember2013.sched.org.

12:05pm

Current information architecture of OpenStack UI is experiencing various issues (horizontal/vertical scaling, usability, etc) and there is common agreement on its improvement.

Thanks to David Lyle's RBAC support [0] which was added to Horizon and there is plan for its extension, we would like to propose new IA to enhance usability and user experience when using OpenStack UI. I would like to have initial proposal for IA enhancements one week before Summit (link should appear in related blueprint).

In this session, I would like to: * shortly cover current state and explain usability issues, * introduce initial proposal of IA improvements, * open discussion and try to find agreement on its future look and regulations when new sections are being added.

12:05pm

Horizon cannot hope to keep up with the number of new services provided by the continually growing set of projects. Other dashboards (such as the AWS console) use dependency injection and code generation from schemas to allow the burden to be largely automated. Let's discuss how this might work in Horizon and how we can move more of that workload onto the projects creating these features.

A couple of suggested approaches:

* An approach that combines Progressive Enhancement with the automated consumption of simplistic HTML generated by the remote projects would allow the Horizon team to focus on enhancing the user experience.

* The Django admin builds complete admin interfaces based on Django's "Model" classes. If we could consume a specification from each service for their "models" we could do some introspection and code generation and end up with something very powerful and flexible.

NOTE: This session was originally proposed for Keystone, but it really belongs under Horizon. Horizon is going to need to set the standards for the other projects in order to continue to have a workable growing UI.

NOTE 2: This session proposal has been edited by Gabriel Hurley to merge two related topics into one.

9:00am

We mock a lot and end up relying heavily on manual testing to find out when one of the many APIs we depend on has changed in a backwards incompatible way, and other surprises. Horizon would greatly benefit from a wider set of integration tests that also exercises all of our interfaces to other projects.

Suggestions and issues to work through:

* How to write useful, durable tests that won't need to be modified all the time because e.g. a button's location has been adjusted?

* Implementation ideas:

* Separate, self-contained new tests?

* Part of the Django Selenium tests?

* A "mocking" switch that could turn mocking on or off: in e.g. a fully set up devstack environment, run the tests without mocking?

* Other ideas?

* Where should they live: in our tree to be easily modified alongside the main code, in Tempest, elsewhere?

9:50am

This will likely tie in to the session proposed by Jeremy about the future direction of Openstack Dashboard and UX, but would like to discuss the following - 1. Give a brief introduction to the new "Router" dashboard and demo how it is used. Find a better permanent solution for this dashboard? 2. What can be done to add new dashboards in future (UX perspective)? 3. Given that we now have a new "Router" dashboard, can we leverage that to add new panels for other hardware? Or will each hardware device require it's own dashboard? 4. Can multiple such dashboards/panels exist at the same time? 5. What can be done to make the operation of these dashboards dynamic - based on plugin detection, config setup?

11:00am

Horizon (OpenStack Dashboard) has a lot of potential for improvements from the look and feel of the UI. In this session I would like to open and discuss: * How to approach UX related questions and include UX professionals into development processes * Which parts of Horizon we can attack in the future * Propose and discuss some ideas for improvements * Open discussion

11:50am

Currently adding stuff to horizon requires to change settings.py. This is nearly impossible in a world of software packages. At least, when using RPM packages, it is absolutely unwanted, to change files at install time, depending if other packages are installed or not. When implemented, this feature would make the life of packagers easier.

The idea would be a directory to place python packages to be added dynamically to the dashboard.

I'd like to hear opinions, ideas, and discussions about managing dynamic plugins, dependencies, etc... Having such a feature would allow others to have their customization separate from horizon, or to provide software vendors to ship functions on top of horizon.