On 08/24/2011 06:38 PM, Jason Guiditta wrote:
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
If Ken approves this is going to be removed (which I'm not sure now), we
add this to current sprint. Thanks.
Jan