Sending scenarios which remained for tomorrow call:
- 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.
- As a user I want a UI to enable browsing of images in the warehouse to which the user has permission, and which can be launched in the current pool.
- As a user I should be able to share identity in Conductor and katello
- As a user, I need UX design for inputting of launch time parameters.
- As a developer, I need UX design for the management of roles & permissions.
Jan
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.
On Wed, Aug 24, 2011 at 12:18 PM, Jan Provazník jprovazn@redhat.com wrote:
UX scenarios description from Ken:
- **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.
- **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.
- **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?
- **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.
- **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.
- **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
On 08/24/2011 06:38 PM, Jason Guiditta wrote:
On Wed, Aug 24, 2011 at 12:18 PM, Jan Provazníkjprovazn@redhat.com wrote:
UX scenarios description from Ken:
- **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.
- **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.
- **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?
- **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.
- **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.
- **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
On Aug 25, 2011, at 3:25 AM, Jan Provaznik wrote:
On 08/24/2011 06:38 PM, Jason Guiditta wrote:
On Wed, Aug 24, 2011 at 12:18 PM, Jan Provazníkjprovazn@redhat.com wrote:
UX scenarios description from Ken:
- **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.
- **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.
- **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?
- **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.
- **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.
- **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@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@redhat.com http://twitter.com/kenkeiter IRC: tigger or tiggerer
aeolus-devel@lists.fedorahosted.org