Open VirtualDOMinic opened 5 years ago
Name | URL | Found Via | Relevant To | Specifically For | Notes
"Relevant To" means who the resource is useful for (e.g. could be everyone), and "Specific For" means which ones are targeted by the resource (e.g. an online course might be relevant to everyone but not specifically for anyone)var userSelection = {
age: true,
ethnicity: false,
gender: true,
disabilities: false,
...
}
Also worth having another (or nested) object for the more specific settings?
var furtherDetails = {
name: "Jane Doe",
country: "United Kingdom",
postcode: "SE0 0XX",
age: 42,
gender: "female",
...
}
Sample database: Have started one (see link) but happy to use an Airtable instead. https://docs.google.com/spreadsheets/d/1erZIoiyDLgFownWDZw8hAJtCoZdUt_Qiblxz9WdoBMk/edit#gid=0
Updating the database. Providing links to events (e.g. meetups, workshops, courses) requires updating the database continuously. For the MVP, this shouldn't be a problem. For the 'real' thing, this raises the question of whether events should be updated manually by a human being or whether there's an automated way of doing this. APIs Aisha suggested using the Meetup API, but most events need to be hand-collected. Q: Is it a good idea / feasible in the available time to use a mixture of APIs and hand-entered events?
User results If we're focusing on a mobile app, users are less likely to want to print out their results directly, but may well want to get their results e-mailed to them in a usable form (e.g. clickable links; a PDF). So maybe we could/should integrate that ability and make it available to all users, without requiring them to make an account?
App purpose should be clear on the splash screen
A longer explanation and instructions on the 2nd screen
Invite users to save their preferences (i.e. sign up / create a profile) or carry on as guests on the 3rd screen, before they launch their search?
Topic tags. Perhaps start with noting down as many different (relevant!) topic categories as we can think of, then iterate & merge until we end up with a number of tags that we can display on (ideally) one screen? That'll be a trade-off between breadth vs manageability.
Search mode. One idea might be to ask users to click on all the personal characteristics/preferences that apply to them and all the topics that they're interested in getting info on, then translate that into a database query?
Might be useful to look at alternatives to postgres. If we go for an alternative, I'd personally pick one that has decent documentation.
The same applies to any other tool we use, i.e. choose something that is well-documented.
tech stack: html5, CSS, Javascript Server:Express, Node Database: Psql Testing: Tape, Coverage: nyc Deployment: Heroku eslint, Travis figma, invision
Article on MongoDB vs postgreSQL: comparison of features; when to use either. https://www.sisense.com/blog/postgres-vs-mongodb-for-storing-json-data/
https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility/
https://adamsilver.io/articles/the-disadvantages-of-css-preprocessors/
In a referenced survey: used in about 1 in 2 websites. https://users.encs.concordia.ca/~nikolaos/publications/SANER_2016.pdf
"Planning tech stack, software architecture etc"
Labelled as an epic, as this may go on to reference several other, smaller issues.
Time 4h - 1d
Please comment (if you'd like) any/all ideas about project architecture, db structure, tools, considerations (e.g accessibility), etc: