This repository has been archived by the owner on Dec 9, 2024. It is now read-only.
forked from cliveeee/dip-programming-prj-advanced-gui-evolve
-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
13 changed files
with
328 additions
and
46 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,108 @@ | ||
# Overview | ||
|
||
As part of the project, you and your team are required to evidence that you have **designed** an advanced user interface that is fit for purpose. | ||
|
||
The following guide will help you ensure that you have met the evidencing requirements while ensuring that you can work in an agile/iterative way that is appropriate for the project and modern software development practices. | ||
|
||
## Design Evidencing | ||
|
||
Modern design approaches are lightweight and combine iterations with user feedback. This is in contrast to traditional design approaches that are heavy on documentation and require a lot of up-front work. | ||
|
||
However, often we cannot access the user in the frequency that allows rapid iteration. One way to mitigate this is to develop personas and scenarios that represent the user and their goals. This allows you to make design decisions based on the user's needs and goals. | ||
|
||
### Minimum Requirements | ||
|
||
1. In your project repository, create a folder called `design`. | ||
2. In the `design` folder, create a file called `persona.md` that describes the key persona your team was focused on implementing the design (see below for detail) | ||
3. Create a subfolder with any design artefacts you created: wireframes, sketches, mockups, etc. | ||
4. If you are treating the application itself as a prototype, highlight what changes if any you made to the application by referencing the appropriate issues | ||
5. Create at least three github issues related to the design of the application: | ||
1. Tag each issue with ui-design | ||
2. Assign each issue to a team member | ||
3. Include a user story in the format "As a [persona], I want to [goal], so that [reason]" | ||
4. Add any non-functional requirements as notes in the issue | ||
6. Copy this document into your project and answer any relevant questions | ||
|
||
## Personas | ||
|
||
A persona is a fictional character that represents a user. It is a way to describe the user's goals, needs, and behaviors. They are focused on **empathy** and **understanding** the user, not demographics, and not a collection of features. | ||
|
||
> Describe the key persona your team was focused on implementing the design. You can describe the persona in a file called `persona.md` in the `design` folder. | ||
> | ||
Pick the most representative persona from your group. Write a brief (2-3 sentence) justification for why you chose this persona. | ||
|
||
"I want to be able to access all the codes at once. I'm busy with school and work, I don't have much time." | ||
|
||
### Persona Template | ||
|
||
This is an optional template for how to structure your persona: | ||
|
||
```markdown | ||
# Persona: [Persona Name] | ||
|
||
## Background | ||
Give the person's background - make sure we can understand their level of skills, knowledge, and experience. | ||
|
||
## Goals | ||
Why does this person use the application? What are they trying to achieve? | ||
|
||
## Needs | ||
What does this person need from the application? What are their pain points? | ||
|
||
``` | ||
|
||
### Relevant issue | ||
> | ||
> Link to an issue that covers a pain point relevant to the persona and explain why it is relevant. | ||
> | ||
### Validation | ||
|
||
You will validate your design by meeting with a user representative: the product owner (in this case, your lecturer). | ||
|
||
##### Meeting minutes | ||
|
||
- [x] Meeting held on [date] 11/06/2024 | ||
- [x] Persona discussed: [persona name] All of them | ||
- [x] Design artefacts reviewed: [list of artifacts] | ||
- [x] Issues discussed: [list of issues] | ||
- [x] Feedback provided: [feedback] | ||
|
||
##### What worked well | ||
|
||
- [ ] [list of things that worked well] | ||
- different personas | ||
- exploring different models | ||
- watching youtube videos of blind users | ||
|
||
##### What could be improved | ||
|
||
- [ ] [list of things that could be improved] | ||
- validating interaction models (trying it ourselves) | ||
- start easy | ||
- more thoughts on designing | ||
- | ||
|
||
##### What will you change before the next meeting | ||
|
||
- [ ] [list of things that will be changed before the next meeting] (no commitment to complete this) | ||
- create a wireframe for getting to the nearest capture. | ||
- what if the next capture is 5 minutes away? | ||
- what if the file isn't fully processed yet? | ||
- examine how Ollama can be packed and shipped | ||
|
||
##### Were there any questions that needed to be discussed with the user | ||
|
||
- [ ] [list of questions that need to be discussed with the user] | ||
- whether the user wants to start with the code, or with the video. | ||
|
||
#### Lecturer's checklist (to be used by the lecturer) | ||
|
||
- [ ] Persona is well defined | ||
- [ ] Persona is relevant to the application | ||
- [ ] Design artifacts are present and easy to follow | ||
- [ ] Design decisions are based on user needs and goals | ||
- [ ] Appropriate considerations of interaction patterns appropriate for the user | ||
- [ ] Efforts towards realizing at least one significant issue involving user interaction | ||
- [ ] Whole team engagement in the design process |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Oops, something went wrong.