Next Release Plan

These are things that we will be aiming to include in the next release.

Client

• An improved screenshot-confirmation display, featuring a more readable step list and some sort of tabular/well-packed view of relevant variables ('Expand to fill screen: Yes', for example)
• The ability for users to view the most recently captured screenshot (if one exists) or the reference screenshot before they commit to capturing an image, to avoid mistakes
• A strong error-reporting system, encapsulating every action, so that users are never left wondering why something failed (also so we can debug stuff quickly)
• Decoupling of project-specific features (We would still maintain an Ubuntu Manual-specific series of patches officially, though, and apply them whenever building release versions)
• Full support for localization of static text and labels
• Once the client authenticates and pulls the core data it needs from the server, it should display any important messages it received. This will allow server admins to quickly notify every client of any problems or updates, without requiring them to check a website or feed of some kind
• Server-provided environment variables. Rather than relying on values set inside of Quickshot for things like screen resolution and panel margins, this information should be pulled from the server when grabbing the MOTD data
• Like the ubuntu install, there should be two password input boxes so that the user can get the password right before continuing.
• Protocol versioning for communicating with servers, so that older servers will work with newer versions of the client and outdated clients will be able to inform the user that an update is available.
• A multi-project design that reads '.qsproj' files (or something like that) to determine which server to use and how to authenticate, allowing a single installation to be used for an infinite number of tasks
• A online help on how to use quickshot covering everything needed for the user or sever admin. Expose this to users through the help menu. "Online help..." link or a help dialogue.
• A more wizard-like design, in which the first uncaptured screenshot is always displayed with a "Next" button. If the user doesn't want to take that screenshot, there should be a "View list" button that takes them to a window similar to that featured in 0.0.8 If all screenshots have been taken, the list should be the only window show

Server

• Support for multiple projects on a single server
• Support for multiple language translations within a single project This means the ability to translate the 'steps' and 'summary' fields in the dictionary, to make it easier to explain things in other languages, where the fallback language (whatever's in the master dictionary file) would be particularly hard to understand
• Some sort of server-side review process, which walks the user through every collected screenshot for a language and allows them to flag the ones they want as final or to remove those that are rejected This will break the dependence on bzr, making Quickshot more portable It will also make everything faster, since the only data source will be the local filesystem
• If things are faster, the client could query the server after every operation, to decrease the possibility of duplicated work
• Served image data should probably be in reduced-quality JPEG/indexed PNG form, since preview-quality is likely acceptable. Unconverted data should be accessible on-demand, though.

• More pretty! The current interface is very primitive and unpresentable <<<Done

• Support for project-based branding is important if the server is to ever be integrated as part of a project's website
• Proper CSS is necessary, too

• PHP should be used to automatically generate the progress images so we can have cool things like gradients, rather than a resized 1x1 block <<<Done

• Better progress reporting and layout formatting are required
• More object-oriented and refactored and commented
• The server's code is pretty much just a bunch of procedural calls, with unnecessary importand and references. This has to be changed
• quickshot.ubuntu-manual.org needs content

Road Map

25th April 2010 Decide on a coding style for the project: naming conventions, documentation style, whitespace practises. Something simple so we can quickly identify what objects map to what elements

19th June 2010 Redesign client GUI to make everything easy to test and modular.

Middle of July Redesign web system to make everything accessible and managable using a browser, to allow for development deployment on any server