Project Specification
Notes Application
Your team will develop an amazing note taking application this term.
A note-taking application is a standalone application designed for recording and searching short, ad-hoc notes. Typically they are used by people as an informal way of organizing information for their own consumption e.g. code snippets, recipes, daily journal notes, or managing a TODO list.
Although there are many different designs, the focus of every note-taking application is storing and managing text notes. Common features include adding, editing, deleting notes, as well as ways to organize or search them.
Commercial examples include: Bear (iOS and macOS), Microsoft OneNote (Windows, macOS, iOS, Android), and Apple Notes.
- Apple Notes started out just supporting rich text, but expanded to include images, tables and drawing on iPad.
- Bear uses Markdown for text entry, and is optimized for speed and ease-of-use.
- Microsoft OneNote is optimized for creating multi-format notes containing rich text, floating images and other content.
These are all valid, but different, interpretations of how to address this particular design space (and they all include advanced features which we don’t expect you to emulate).
There are even command-line applications which attempt to solve the same issue. For example, here’s Terminal Velocity on Linux, optimized for very quick note entry, for users who are accustomed to working from a terminal.
These are commercial applications that have taken years to design and build, so I certainly don’t expect this level of functionality! However, they might give you some ideas of one or two key features to include that are feasible given the time that you have.
Determining Requirements
Your team will develop an amazing note taking application to complete with these designs! You will speak with users, gather requirements, make design decisions and implement your own vision.
For this course, the instructor and TAs are all potential users. You can talk with them to get their opinions. You should document what they tell you, and consider their input when defining your requirements. Keep in mind that - just like real users - their ideas are sometimes terrible. They also might forget what they told you previously, contradict themselves, or suggest features that can’t possibly work together. Part of your job is to “sift through” what they tell you, and make the best decisions that you can, to build a great application.
Minimum Functionality
The following section describes what I would consider minimum functionality for any application. You need to include these features (and you are expected to build much more than just this).
- Your application should be easy to launch. There should also be a way to exit.
- If this is a desktop application, the application window should be resizable. Ideally, you should save the size and position of the window, or other application properties, and restore it when it’s relaunched.
- If this is a mobile application, it should be full-screen. You don’t need to handle resizing.
- You should adhere to the conventions for that particular platform:
- Desktop: everything should be optimized for mouse and keyboard, and as much as possible you should support keyboard shortcuts (e.g. hotkeys). You should strongly consider having menus, with menu items for all major functions.
- Mobile: you should determine and use standard gestures for the functionality that you are supporting. Look at some similar apps if you’re unsure what these should be.
- Functionality should be discoverable i.e. users should be able to easily figure out what they can and cannot do!
- Data should never be lost!
- Desktop: if the user has entered data and exits the application, you should never just discard and lose the data – prompt the user to save or discard it.
- Mobile: rotating the device, or exiting the application should never lose data. The convention on mobile is to automatically save and restore data without prompting the user – you should do that.
- Plan to store data in the cloud.
- In Sprint 3, you will modify your application to save your note data in the cloud (i.e. on a separate system). You are not expected to design for this until later in the course.
Questions to Consider
Here are some questions that you and your team should ask yourselves, and your potential users! The answers to these will help form your core requirements.
- How will this application be used? What are my users like? What features would they care about?
- What platform would work best? Where does this need to run? Would a desktop or mobile app work better?
- What do we need to store in the notes? Text? Formatted text? Images? Sounds? Other files?
- What other functionality might we need: searching? grouping notes somehow? linking notes together? copy-paste between notes? (Brainstorm!)
- How can I design this in a way that supports multiple application instances? How does this affect my architecture & design?
Similar Applications
Here’s an incomplete list of similar applications. Use these to get a sense of what features you might want to consider, or some design approaches.
- Apple Notes - Closed Source. macOS and iOS.
- Bear - Closed Source. macOS and iOS.
- Evernote - Closed Source. macOS and iOS, Windows and Android, Web.
- FSNotes - Open Source. macOS and iOS.
- Google Keep - Closed Source. iOS and Android, Web, Chrome.
- Joplin - Open Source. macOS and iOS, Windows and Android.
- Notion - Closed Source. macOS and iOS, Windows and Android, Web.
- OneNote - Closed Source. Windows, macOS, iOS, Web.
FAQ
1. Are we supposed to know how to do this?
No, not yet! We will work through all that you need to know in lectures. We have lots of time, and we will work through each stage togethere.
2. How do I figure out how to do all of this?
The lectures are meant to complement align with what your team is working on (e.g. you will watch Design videos and we’ll talk about Design before you need to do that part). For the first few weeks, I will be telling you exactly what you should be doing. Once we start into sprints, things will be less structured, simply because teams will likely have different approaches and different requirements to address.
There’s a few things that are meant to help you once you’re in a sprint.
- Course staff are available. We can help you make decisions, prioritize items, and even get past some technical hurdles.
- We will make supplemental material available as needed. e.g. need to know how to run something in a background thread on Android? Ask us and we’ll provide notes, articles, sample code, or even videos.
3. Is this all Kotlin?
Yes, Kotlin is very flexible and you can build everything in Kotlin + libraries/frameworks.
4. Can we use third-party libraries, or are we supposed to build everything from scratch?
You can, and should, use libraries where appropriate - that’s why they exist! They’re often well-designed and tested, and using them can result in much a higher quality product (plus, they save time). You can even use third-party source code, within limits - see the course policies, specifically around what constitutes plagiarism. Tl;dr. You can external source code as long as a single source doesn’t constitute more than 10% of your project. More than that, and it’s considered a potential academic integrity offense. If you have questions about this, please just ask.
5. Can we pick our own project?
No, there’s simply not enough time for us to manage arbitrary projects like that. Capstone project, for instance, are always at least 2 terms long - and the entire first term is needed to get the requirements correct! We’re choosing a project to streamline the process, so that you can have requirements done reasonably well in weeks instead of months.
6. Are these requirements complete?
No, they’re not even close to complete! Think of them as a starting point for your team. From here, I expect you to
- Review some of the competing apps that have already addressed this problem, to understand some possible approaches,
- Interview users (the course staff) and ask questions - get opinions from them on what they might like to see,
- Brainstorm with your team and come up with some more questions, or more features that you think could be useful!
- Consider building an affinity map, or user story map to capture different requirements,
This should get you a very large list, and from that list you will need to decide on a smaller subset of features to actually build.
7. So, we can just pick the simplest thing to build and get an A?
Umm, well, no. I expect you to deliver a functional application that meets basic user expectations:
- Some features should become clear as soon as you consider how this application will be used. e.g. you need the ability to add a new note, delete a note, search notes. Brainstorming and speaking to users should make these obvious.
- Other features are part of the platform and should be considered critical e.g. resizing on a desktop OS.
- Your grade will depend partially on how far you go above the “bare minimum” functionality. See the course project guidelines for an idea of what we mean by this.
8. So if there isn’t a firm specification, how will I be graded?
You will be graded on a sliding scale, for a number of different factors: if your requirements are coherent and consistent, if your design meets your requirements, did you deliver the features that you said you would deliver and so on. We will also grade you based on how well your product works of course, but every project will be graded on how well you planned and executed the project.
Every project has rough patches, where there’s a bug that you cannot get past, or a feature that just doesn’t work, or where you need to back up and rethink a requirement. That’s fine and expected! What matters here is that you (a) admit what happened, (b) communicate with your team and stakeholders, and (c) have a reasonable to plan to address it.
9. If we are all building the same thing, how are you handling academic integrity? Won’t we all get flagged?
You are all designing and building different versions of the same basic application, so it’s unlikely that we’re going to see large sections of duplicate course code.
However, I recognize that this could be an issue. See the plagiarism policy for this course. You are allowed up to 10% overlap from any single source - just make sure to cite it and include in a README (and include as an Appendix in your final report).
This is partially done to avoid the issue you’re describing and partly because I don’t mind if you use a snippet that someone found on Stack Overflow - as long as it’s a relatively small part of your overall project.