Problem Statement: Currently most web applications use the standard
http file browse and upload service provided with the
<input type="file"> form field.
- Only one file can be selected at a time for upload.
- Interface is inconsistent from browser to browser even down to the labels on the browse button.
- The application can not specify the file type or types that are accepted in the current context.
- The browser does not provide meaningful or consistent feedback on the upload process.
Catalina and Christy are some of the users whose needs we primarily considered when designing the Uploader.
Fluid Personas are a collection of various types of important users whose needs we need to consider throughout the design process.
3. Users' needs
Context of use: In what context would the user need an Uploader?
- uPortal File Upload Contexts of use
- OpenCollection File Upload Contexts of use
- Sakai File Upload Contexts of Use
- Uploader Scenarios and Use Cases
Primary & Secondary Scenarios:
Wireframes What does the Uploader look like and how does it behave?
Storyboards: How, when, and where would the user use an Uploader?
- Uploader Storyboard - Simple Upload
- Uploader Storyboard - Upload with Error
- Uploader Storyboard - Upload and Cancel
- Uploader Storyboard - Add more
User Testing Protocol: Describes how the user testing of Uploader will be carried out
User Testing Results: Describes how the users interacted with the Uploader prototype and what improvements can be made
6. Preparing for Implementation
Storycards: Decomposes the Uploader into small implementable chunks
IE Story 1 (FLUID-775): Allow user to edit a simple, single piece of text without leaving their context