DesktopJuJu

Revision 10 as of 2012-05-16 21:17:28

Clear message

Summary

This specification presents ideas to develop a desktop framework similar to what JuJu does for the web.

Rationale

A framework that allows users to easily use predefined sets of actions across all aspects of the desktop presents an interesting opportunity to redefine the desktop metaphor.

Such a framework could be extensible for all strata of user experiences; the system level, inter-application, and intra-application.

Existing knowledge bases can be distilled into predefined sets of actions. This framework would leverage these sets of actions and/or heuristically derived system data to yield the following:

  • simplification of user experience by minimizing computer and application knowledge/experience requirements (i.e. it becomes easier to use)
  • greatly enhance problem solving (i.e. the computer provides smart solutions)
  • users experience enhanced functionality and greater capability at a more rapid rate (i.e. users can do more)

Crowd sourcing sets of actions could be implemented as well. Curation and packaging would be required, but developing an API or application should increase efficiency and quality.

Since Juju and Charms were the catalyst, the blueprint authors denoted the framework 'Vudu' (pronounced as 'voodoo') and the sets of steps as 'Spells', which will be used in later parts of this document.

User Stories

Due to the difference in development requirements, the User Stories are subdivided into the three different strata; system, inter-application, and intra-application.

system strata

These use cases will address how users might interact with the operating system.

  1. johnny wants to add a network printer
  2. barbara can't connect to the internet
  3. barton wants to create an magazine for print

inter-appliction

These use cases will address how users might interact within a single application .

  1. sachi wants to repetitively retouch photos from a social gathering sharpen, crops, and rotates the images.
  2. Jean-Pierre wants to

intra-appliction

These use cases will address how users will interact with the operating system.

  1. Phillipe wants to record his band and needs to start five applications, load templates, and make audio routing connections.
  2. adjoa wants to

The rest of the specification

Replace that heading with headings for each thing you’re changing or specifying.

Checklist:

  1. Have you reviewed the bug reports for the relevant package? (Yes, this may take an hour or two. But you might be able to fix multiple bugs with a well-designed change.)
  2. If any user interface is involved, is it fully described? Include any wireframes or mockups.
  3. Have you had any new user interface, or new visible text, reviewed by a designer? (Or if you are a designer, have you had it peer-reviewed?)
  4. Is the change accessible? (For example, have you specified accessible labels for any graphic-only elements?)
  5. How will users learn the new way of doing things? Describe any help pages required, and any changes to the Ubuntu Web site or installer slideshow.
  6. Is any migration of data or settings required?

  7. How will the feature be tested? Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

Unresolved issues

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.

stuff to add (probably)

schedule and visibility

  • mark said this would happen not this cycle (presumably quantal) but next cycle (presumably r-cycle)
  • what is the visibility of this project? can we blog about it?
    • charles profitt said he asked mark and was told we can blog about it
    • should we confirm this again?

features

  • suggested
    • three strata (system, intra-application, inter-application)
    • user defined spells
    • users can edit or create their own spells
    • default spells packages
    • crowd sourced spells (required curation and packages)
    • use HUD or the dash for interface
    • might use natural language and fuzzy logic
    • heuristically solve problems or determine appropriate spells
    • might provide list of possible solutions with most probably default selection, user chooses
    • help users solve problems
    • help users with repeating actions within single application
    • help users start sets of applications, change appropriate settings, make connections, or copy files
    • help users install sets of packages to support objective/task
  • possible
    • API or app to help users create spells
    • "macro recorder" to help users create spells

design

  • juju/charms was the original inspiration and remains analogous system
  • use dbus probably
  • apps probably need patches to expose settings to dbus
  • libvudu perhaps to simplify process
  • juju/charms originally considered as usable framework, but currently found to be improper
  • the ladish project (in launchpad) is an example of an intra-application strata solution

artwork

  • logo ideas
  • ad video idea

misc

  • mims said to look at QML to define profiles rather than packages
  • mhall said to make sure vudu spells work and translate to tablets, phones, and tvs

CategorySpec