Wimpy Point Application Requirements
by
Dennis Gregorovic
I. Introduction
This document describes the requirements for the ACS Wimpy Point application. The
Wimpy Point application enables users to build slide presentations from their
web browsers.
II. Vision Statement
WimpyPoint is a web-based application for building slide presentations that
replaces desktop bloatware such as Microsoft PowerPoint. You can build a slide
presentation in WimpyPoint from any Web browser anywhere in the
world. WimpyPoint will hold onto your presentation in a relational database
management system. You can forget your laptop. You can drop your laptop. You
will still be able to give your presentation anywhere in the world that you can
find a Web browser.
More interestingly, WimpyPoint lets you work with colleagues. From your desk at
MIT, you can authorize a friend at Stanford to edit your presentation, the two
of you can work together until you're satisfied, and then you can both go into a
conference room at Hewlett-Packard Laboratories and give your talk from our
server.
III. System/Application Overview
WimpyPoint will consist of a user interface for creating, editing, and
presenting slide-based presentations. WimpyPoint will not need an API for
developers or a user interface for administrators.
IV. Use-Cases and User Scenarios
Creating a Presentation
Sal Salesman wants to create a slide presentation to promote his company's
latest product to potential customers. Sal goes to the WimpyPoint application and
clicks on a link to create a new presentation. Sal is prompted to enter
information about the presentation such as color scheme, summary, etc. Then Sal
creates slides to go into the presentation. Sal can edit each slide as well as
change their order. Sal can also decide whether to make the presentation
public or private. If private, he chooses who is allowed to view it.
Viewing a Presentation
Sal Salesman has created a slide presentation to promote his company's latest
product. He mentions the slide to a Joe at Green Plant Inc, a potential
customer. Later that day Joe visits WimpyPoint. He searches for presentations
created by Sal, and finds the one he wants. By clicking on the prestation
title, the first page of the presentation is displayed. Joe then uses the
navigation links to proceed through the presentation and is so impressed with
what he sees that he calls Sam to order the product.
V. Related Links
VI.A. Requirements: Data Model
1 Data Model
1.1 Styles
1.1.1 Each style should have color values for text, background, regular links, active links, and visited links.
1.1.2 Each style should allow for arbitrary Cascading Style Sheet code.
1.1.3 Each style should allow for a background image.
1.1.4 Each style should be owned by a single user.
1.1.5 Each style should either be public or private.
1.2 Presentations
1.2.1 Each presentation must have a title.
1.2.2 Each presentation may have a page signature.
1.2.3 Each presentation may have a copyright notice.
1.2.4 Each presentation may have one style associated.
1.2.5 Each presentation must either be public or private.
1.2.6 Each presentation may have a description of the audience.
1.2.7 Each presentation may have a description of background information.
1.2.8 Each presentation may have access control given to a group of users.
1.3 Versions
1.3.1 Each presentation can have an arbitrary number of versions, which are frozen snapshots of the presentation.
1.4 Slides
1.4.1 Each slide belongs to exactly one presentation.
1.4.2 Each slide may have a title.
1.4.3 Each slide may have a preamble.
1.4.4 Each slide may have a list of bullet items.
1.4.5 Each slide may have a postamble.
1.4.6 Each slide can either be included or excluded from presentation outlines.
1.4.7 Each slide may or may not have a context break after it during the slide show.
1.4.8 Each slide may have its own style.
VI.B. Requirements: Administrator Interface
NONE
VI.C. Requirements: API
NONE
VI.D. Requirements: User Interface
4 User Interface
4.1 Finding Presentations
4.1.1 The user should be able to see a list of presentations that he
can view.
4.1.2 The user should be able to see a list of just his own presentations.
4.1.3 The user should be able to search for a presentation by the
author's name.
4.1 Creating Presentations
4.1.1 The user, once logged in, should be able to create a new presentation.
4.1.1 When creating the presentation, the user can fill in
information like title, page signature, copyright, style, etc.
4.2 Editing a Presentations
4.2.1 The user can insert a new slide.
4.2.2 The user delete a slide.
4.2.3 The user can change the ordering of the slides.
4.2.4 The user can attach a file or image to a slide
4.2.5 The user can edit the presentation properties.
4.2.6 The user can adjust which slides are included in the outline.
4.2.7 The user can edit context breaks.
4.2.8 The user can bulk copy slides from another presentation.
4.2.9 The user can upload an archive of images as slides in the
presentation.
4.2.10 The user can delete the presentation.
4.2.11 The user can change the people that may view and / or edit the
presentation.
4.2.12 The user can create a version of the presentation.
4.2.13 The user can revert the presentation to a previously saved
version.
4.3 Adding and Editing Slides
4.3.1 The user can add, edit, and delete slides.
4.3.2 Each slide can have a title, preamble, postamble, and list of
bulleted items.
4.3.3 The ordering of the items in the bulleted list can be changed.
4.3.4 The user can upload attachments to each slide.
4.4 Viewing a Presentation
4.4.1 Viewing a presentation first entails showing a title page with
the presentation title, authors, and list of slides.
4.4.2 From here the user can click on an individual slide to display
that slide.
4.4.3 There should also be a link to start the slide show, which will
display the first slide.
4.4.4 When viewing a slide, in addition to the slide information
being shown, there will be links to view the next and previous slides. There
will also be a link to return to the top of the presentation.
4.4.5 The presentation by default will be displayed in the style chosen by the
author. However, the user should be able to change this, either for the session
or permanently.
VII. Revision History
Document Revision # |
Action Taken, Notes |
When? |
By Whom? |
0.1 |
Creation |
22-Sep-2000 |
Dennis Gregorovic |
0.2 |
Revised |
02-Oct-2000 |
Dennis Gregorovic |
dennis@arsdigita.com