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
_______________________________________________
aeolus-devel mailing list
aeolus-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/aeolus-devel
Yes, I definitely approve. I think we're ready to get rid of compass. Not really using
it for anything other than sass.
--
Kenneth Keiter
Sr. Software Engineer, Cloud BU
kenkeiter(a)redhat.com