ShutdownAndRestartExperience

Revision 19 as of 2009-07-28 11:43:01

Clear message

Summary

This specification covers design and implementation details of the Shutdown and Restart Experience in Ubuntu Karmic. Proposed solutions will affect the structure, look&feel and functional aspects of the Usplash exit screen.

Release Note

Rationale

The new shutdown and restart experience will provide the user with a visually pleasing and smooth transition from the desktop session/gdm into the power-off state. The user will be informed whether he is restarting or shutting down by the appropriate text message on the screen.

User stories

* John wants to shut down his machine after the day's work.

* Ali wants to restart her computer after she noticed some problems with the system performance.

Assumptions

Design

The new shutdown and restart experience should seamlessly conjoin with the newly designed boot experience and provide a smooth transition between the user session and the power-off state.

Shutting down from the desktop session

If possible, a smooth transition should occur between the desktop session and the shutdown screen. When the user confirms the shutdown, the splash screen should fade in instantly on top of the user's desktop.

Shutting down from the login screen

If possible, a smooth transition should occur between the login screen and the shutdown screen. When the user confirms the shutdown, the splash screen should fade in instantly, replacing the login dialog and menus.

Shutdown splash screen (wireframe):

shutdown.png

"It is now safe to turn off your computer" confirmation screen

If the computer's hardware does not support automatic power-off, the system should detect it and present the user with the screen confirming that it is now safe to turn off the machine:

safe-to-turn-off.png

Shutting down with system updates

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

Community artists proposals

I think that some proposal worth to be taken into account (even some of them include boot process as well, there is a part for login).

proposal #1


CategorySpec