Home Index Changes Prefs Log in »
View Attach (4) Info

Scenarios, Use Cases, Roles and Personas

Design and development of Update Center is driven by specific requirements associated with general scenarios, use cases and the roles of users in the scenarios and use cases.

ScenariosGeneral user-oriented situations identified to help define the overall scope of the project its subprojects and organize use cases and requirements.
Use CasesDetailed tasks associated with one or more scenarios andT requirements to flesh out specific user interface and tooling design approaches.
Roles and PersonasRoles are typical responsibilities of users interacting within the scope of the overall scenarios and detailed use cases.

Personas are actual examples of fictitious people that play the roles of interest. Using realistic examples of people helps designers better understand users' backgrounds, preferences and typical work habits.

Scenario Groupings

In the Update Center project there are four groups of scenarios that have been identified to organize requirements and use cases: Original Equipment Manufacturers (OEMs) that incorporate applications and updates to the applications into their own applications.
  • Delivering Binary Distributions: The behind the scenes, upstream activities that occur to make application packages, installable distributions, updates and additions available to the users. Includes 3rd parties and other projects contributing packages to repositories.
  • Integrating Binary Distributions: Other open source projects, Independent Software Vendors (ISVs) and Original Equipment Manufacturers (OEMs) that incorporate applications and updates to the applications into their own applications.
  • Using Binary Distributions: Developers and administrators ("end users") using applications and managing the installation and update of those applications.
  • Connecting with Users: Community and product leads leveraging connections with users to better understand users' needs and to constantly improve applications, services and information provided back to users.
Scenario Groupings
Scenarios-> Delivering Distributions

Delivering Binary Distributions

Overview

Scenarios in which behind the scenes, upstream activities make application packages, installable distributions, updates and additions available to users. Includes 3rd parties and other projects contributing packages to repositories.

Roles of Delivering Distros

Scenarios

IDTitleDescription
DEL.1General Repository ManagementRepository managers control integration of packages from projects into shared package repositories that are used by downstream groups to assemble distros and images and to expose updated and add-on packages to users.
DEL.2Distro Release DefinitionDistro owner defines the content of distro. Triggers establishment of distro release-specific package repositories. Content for a distro may come from a general package repository.
DEL.3Package IntegrationPackage maintainers produce new and updated binary packages and integrate into general and/or distro-specific package repositories.
DEL.4OS Package IntegrationPackage maintainers product new and updated OS distro-specific packages and integrated into OS distro-specific package repositories.
DEL.5Distro Release Repository ManagementDistro maintainer accepts new and updated package content into distro release-specific package repository.
DEL.6Installable Distro AssemblyDistro assembler produces downloadable, installable from scratch distribution that includes an install application, update center client tooling and packages from package repository.
DEL.7Deployable Image AssemblyImage assembler produces deployable image that includes pre-installed packages and update center client tooling.

Open Questions / To Do

  • Identify compile-time binary repositories vis a vis distro assembly-time package repositories. Might be a separate set of scenarios associated Maven and such compile-time repositories.
  • Identify distinction between the scenarios above in the context of open source binary distros and commercial binary distros.
    • Likely different package repositories: outside the firewall, freely accessible and associated with open source project vs controlled access in support of users of commercially support binary distros
Scenarios-> Integrating Binary Distros

Integrating Binary Distros

Other open source projects, Independent Software Vendors (ISVs) and Original Equipment Manufacturers (OEMs) that incorporate applications and updates to the applications into their own applications.

IDTitleDescription
INT.1...scenario title...including link to detailed description page......description...
INT.2...scenario title...including link to detailed description page......description...
INT.3...scenario title...including link to detailed description page......description...
Scenarios-> Using Binary Distros

Using Binary Distributions

Overview

Scenarios in which developers and administrators or "end users" install, use and manage applications.

Multiple contexts:

  • Desktop
  • Server Deployment
  • Browser-based Interaction with Hosted Repository Services

DesktopDeployment
The world in which developers and administrators install, use, trial and manage applications on their desktops and laptops.

Multiple applications configured together on the same system for:
* Development
* Experimentation, Trial Use
* Simple deployments

GUI install and package management tooling is a must have

Desktop integration is helpful
* Update notifications
* Start menu integration
* Ease of managing multiple installations

Sometimes disconnected from the Internet

Windows, Linux, Mac, and Solaris support is necessary		The headless server deployment world in which remote deployments are provisioned, tested and maintained. Both developers and administrators work in this context.

Headless installations and updates for:
* Development servers
* Integration testing
* Pre-production staging
* Production deployment.

Application deployments configured across OS instance boundaries

CLI is a must have

Often no direct Internet access is allowed

Solaris, Linux, other Unix and Windows support is necessary

Desktop

IDTitleDescription
USE.DT.1Installing First Product DistroOut of the box initial install experience.
USE.DT.2Administering Product DeploymentWhat happens while user administers the installed product? i.e. How are they made aware of updates and add-ons while working with the product's administrative interfaces?
USE.DT.3Installing Additional or Side-by-side Product Distroe.g. Validating that multiple installations of product distros can live together in different install directories.
USE.DT.4Determining Installed Components Their VersionsUser wants to know which versions of components are installed in a particular install image.
USE.DT.4.1Via UC GUI
USE.DT.4.2Via UC CLI
USE.DT.4.3Via Product's Admin CLI
USE.DT.4.4Via Product's Admin Web UI
USE.DT.5Becoming Aware of and Installing UpdatesEnsuring that users are made aware of updates through multiple avenues.
USE.DT.5.1Via Desktop notification appletNotification area icon is hidden until user needs to be notified.
USE.DT.5.2Via Product Admin Web UI
USE.DT.5.3Via Product's Admin CLI
USE.DT.5.4Via IDE
USE.DT.6Installing an Update Without Internet Access
USE.DT.7Backing Out an Update
USE.DT.8Removing an Installed Package
USE.DT.9Searching for and Installing Add-on ComponentsIncluding the ability to accept or reject license agreements.
USE.DT.10Becoming Aware of Add-on ComponentsPromoting the availability of interesting add-ons to users via multiple avenues.

User should be able to figure out which components he/she already looked at and which were not yet looked at.
USE.DT.10.1Via Desktop notification appletBy default, notify user of newly available add-on components via balloon tip from notification icon.
Notification area icon is hidden until user needs to be notified.
USE.DT.10.2Via UC GUI* When the use launched the GUI to apply updates, ensure the list of relevant add-ons are easily visible.
** Display easy to usertand groupings of components

* Display cross-promotion adverts
USE.DT.10.3Via Product Admin Web UI* Make it easy to list and install available add-ons
* Display cross-promotion adverts
USE.DT.11Becoming Aware of non-Installable Offerings
USE.DT.12Deploying Preinstalled Image
USE.DT.13Removing an Installed Product Distro
USE.DT.14Managing List of Repositories* User should be able add, change and remove additional repository URLs in order to point to and interact with 3rd party repositories
* Ability change order of repositories
USE.DT.15Updating the Update ClientAbility to apply updates to the update client.
USE.DT.16Managing Update PreferencesIncluding:
* Frequency of checking for updates
* Network proxy settings

Open Questions

  • Scenarios in which products are incorporated into an IDE such as NetBeans and Eclipse
    • Multiple update tools vs integrated update tools. e.g. When GlassFish App Server is delivered in a NetBeans distro, does a developer depend on the NetBeans Update Center to make GF updates visible or does the developer have to launch an update tool that works with GF and is separate from the IDE's update tool? We should be striving for the former experience - i.e. Integrated.

Deployment

Headless server-based installations in which administration is occurring via CLI and web browser-based tools.
IDTitleDescription
USE.DEP.1Installing First Product Distro
USE.DEP.2Administering Product Deployment
USE.DEP.3Installing Additional Product Distro
USE.DEP.4Determining Installed Products, Packages and Their Versions
USE.DEP.5Becoming Aware of Updates via Product Administrative UIs
USE.DEP.6Searching For and Installing Updates Over the Internet
USE.DEP.7Installing Additional Features Over the InternetIncluding the ability to accept or reject license agreements.
USE.DEP.8Installing an Update Without Internet Access
USE.DEP.9Installing Additional Features Without Internet Access
USE.DEP.10Backing Out an Update
USE.DEP.11Removing an Installed Package
USE.DEP.12Cloning an Installed Image to Another System
USE.DEP.13Deploying Preinstalled Image
USE.DEP.14Removing an Installed Product Distro
USE.DEP.15Add Another RepositoryUser should be able add, change and remove additional repository URLs in order to point to and interact with 3rd party repositories.
USE.DT.16Update the Update ClientAbility to apply updates to the update client.

Browser-based Interaction with Hosted Repository Services

IDTitleDescription
USE.BB.1Searching for Updates and Additions via Web BrowserWithout access to an installed installation, user search project or product web site for updates and additions relevant to specific distro releases.
USE.BB.2Signing up for Notifications via Web SiteUser accesses project or product web site to sign up for notifications of updates and additions relevant to specific distro releases.
USE.BB.3Notification via Email and RSSUsers receives notifications of updates and additions.
Scenarios-> Connecting With Users

Connecting with Users

Community and product leads leveraging connections with users to better understand users' needs and to constantly improve applications, services and information provided back to users.

IDTitleDescription
CONN.1 Discovering Software in the Repository It should be easy to browse the update center repository content and discover what is popular and worth taking a look. Similar to most online stores, update center UI should have popular softwares in different categories, banners promoting software and services, etc. It should be possible to restrict certain part of the repository to only a class of users.
CONN.2 Knowing the User Through the update center, it should be possible to encourage the user to register in exchange of bug fixes, contents (ex., knowledge base content such as tuning guides, deloyment architecture shows up in the details section for a software), promotions (ex., first 30 day free for support, eng services), etc.
CONN.3 Promotion Channel On the update center UI, it should be possible to promote softwares, support and services. This should be context sensitive and allow videos.
CONN.4 User Reviews It should be possible for end users to write a review for a software with star ratings. Other users should be able to see these reviews and the overall star ratings.
CONN.5 Companion Software For a given software, user should see what other softwares people are typically using.
CONN.6 Product Specific Details It should be possible for users to see software specific details easily. Update center 1.0 has the following information - overview - description of the product, post install instructions, documentation, tech specs - technical details, requirements, features, support - community and commercial support, training, etc. We should retain these information while navigation and layout may change. We should allow software specific banners.
CONN.7 Connecting with User Generated Contents Every software should have a set of tags. In the details section of a software, we should show recent blogs for that software/tags (RSS feed from Technorati, Google, etc.), any screen casts/video (YouTube, Google). Other contents may include books, upcoming conferences/events, promotions, etc.
CONN.8 Getting Help It should be easy for users to report an issue, ask a question (link forums), sign up for support and services for a particular software.
CONN.9 Anonymous Usage Reporting Help users understand popularity of distros, add-ons and updates. Help community and product leads make informed decisions.
« Home Attachments Info Index Changes
This page (revision-27) was last changed on 15-Oct-07 21:37 PM, -0700 by Ckamps