On Wed, Aug 24, 2011 at 12:18 PM, Jan Provazník <jprovazn(a)redhat.com> wrote:
UX scenarios description from Ken:
1. **As a user, I would like to see the next iteration of visual design
of the application (Jiri?, Ken)**
We need to go through and implement the new visual design elements (and
update old ones), ensuring that they don't break elsewhere.
Additionally, we need to consolidate, clean, and simplify our SCSS. This
process includes layout of forms, as well.
2. **As a user, I should no longer see ANY unformatted lists, and should
have basic grid functionality.**
We should now have a reusable, reasonably self-contained filter table
component. When JS is enabled, the table should load its data
asynchronously from the page, and should allow for dynamic filtering
with no reload. With JS disabled, the table should only allow for the
most basic object-level operations. Column reordering/sorting, etc do
not need to be implemented.
3. **As a user, I should see properly-nested resource URLs matching the
hierarchy of the new administer section.**
There are four TOP-level objects in the new administer section; these
are: [Users and Groups, Pools (really 'environments' or 'resource
families', AKA 'pool families), Content, and Providers]. For example, in
the visual hierarchy, a provider may have many accounts, profiles, or
realms. In the case of a provider account, the route for the
Account#show page could look like /providers/4/accounts/1. Same goes for
'environments': the route to Pool#edit should look like
/environments/4/pools/1/edit. Voila! The question is how this integrates
with the monitor section.. Thoughts?
4. **As a user, I should have the ability to enable/disable a provider
in a single, verified action.**
Users need to be able to flick a switch to disable a provider. This
decision should obviously be confirmed in a modal window; running
instances on that provider should probably be stopped.
5. **As a user, I should be able to configure and view information for a
given provider on its detail page.**
Need to be able to pull in the appropriate partials into pseudo-tabs in
the Provider's detail page.
6. **As a user, I would like to see clean deletion confirmation pages
for any top-level object that has the potential to directly affect
instances or people, or permissions.**
Probably something we could implement using JST. Do we want to implement
Jammit or something similar to handle asset/JST management? If so, we
need a story for it.
_______________________________________________
If compass is no longer to be used (which is what I hear), any chance
of including removal of any remaining use of it? Then on infra side,
we can switch over deps/config to just use sass, and lose a couple
more dependencies.
-j