The brand spanking new 2019 build of fitzroyacademy.com
- High level stuff
- What we're doing this year
- Business goals and plans
- Our values and policies
- How we work
- People
- Accounts and logins
- Release process and project management
- Data and governance
- Operational and customer support: Bugs, logging, customers, etc.
- Working with devs: Chat, video, logging, payment, etc.
- The tech
- Video provision
- Design principles
- Front end
- Backend
- DevOps: Hosting, CDN, etc.
The Fitzroy Academy is an online social enterprise school. We create online courses and resources for entrepeneurs, educators and communities.
In 2019 we are rebuilding the entire app, to replace the existing .com with a new app.
We are funded for 2019 to focus on helping our partners achieve scale in South East Asian. High level goals include:
- Rebuild the app fromt scratch using #currentyear dev practice;
- Internationalise the app, starting in Khmer for our Cambodian partners;
- Onboard + test app with 5-10K new users by end 2019;
- Have resilient enterprise-level admin for our institute-level customers;
- Better governance and reporting for our funders, partners, and customers;
- New and more betterer billing + pricing structure;
More on our overall org plans on our public 2019-2020 plan.
We're a social change org, so treating people well is super important.
- Core FA values: One page Google doc on our org-level values;
- Code of conduct: Our standards for behaviour;
- We probably need more high level docs here? - WD
We're a tiny, high quality, distributed team.
We need more people this year. Here's the team:
- @willdayble: Front end, Melbourne, AU.
- @yuffster: Lead tech, Washington DC, USA.
- @quercy: Devops + deployment, Cambridge, USA.
- Maciej: Backend Dev, Torun, Poland
- Saaransh Mehta Data + analytics + ML
We use Google accounts (name@fitzroyacademy.com) as our single point of control for almost everything, so it's easy to give access to everything all at once with one login.
- Github for code repos;
- Trello for project management;
- Intercom for user support;
- Stripe for money.
- TBD
Collecting student data is important, using it responsibly is importanter.
- We aim to be GDPR compliant by default, whilst gathering lots of data for teachers and institutions;
- We will have a public description of all data we collect from users;
- Any user can download a (reasonable) copy of the data we have on them at any time;
- Users can delete their data from our servers (in a way that doesn't break the app).
- Help teachers and institutes do better teaching;
- Better student learning experience;
- Help our team build better courses and lessons;
- Provide benchmarks for student activity to help program managers.
- Intercom for high level customer support.
- Todo: We need a support@ email centralisation thing?
We work remote, so we love devs who:
- Write simple, well commented, clear code;
- Use standard best practice, not hipster-level fashionable frameworks;
- Strongly prefer to work remote than in an office;
- Are chilled out and easy to work with.
We have a bias towards free, simple tools.
- Github for code
- Appear.in for video chat
- Trello for sprints + not forgetting things
- Slack for text chat
- Google docs for writing things down that last
- AWS for infrastructure
We are a poor self-funded social enterprise, but everyone gets paid. No interns! :)
- All devs work hour-by-hour;
- Most devs will have real jobs somewhere else;
- Devs report on how many hours done each month, and are paid via Paypal.
- Speak to Will Dayble about what we need;
- Do a paid trial writing a few hours / a day-worth of code;
- If everyone's happy, agree to a rough expectation of hours / month and sally forth;
Now for the fun stuff, let's build an LMS together...
We use Wistia for video hosting. Video is the most important part of the FA app.
Our core philosophy for visual, experience and app design are our core values extended into a set of principles.
- Use broadly accessible design practices, e.g. Material design or Bootstrap, so that more designers can be involved at a level that suits them.
- Design Ethically. Value impact over form, welcome criticism and know your audience. Mike says it better than we do!
- Play nicely with the whole stack. Drop the ego, avoid edge case hipsterism design fashions.
- Build art together, and share the joy of design with our students, teachers and friends. We shouldn't go more than a few days of design without showing it to someone and asking for their advice.
- People first. The user is not only right, they are good looking and fun to be around. PEBKAC errors do not exist, all user bugs are a designer's problem to fix.
- Be healthy: Design to remove pain and bring joy, not stickiness or addicition. Avoid dark patterns like the plague. Draw something, go outside, throw out the drawing and try again.
- Guess less: Ask important questions of our users, and answer them completely, with good design. Build less tech in response to the most important needs. Make it beautiful!
- Patient impatience: Fix bugs fast, but consider the long term architecture and language of the experience so they happen less.
- Jokes! Get them, make them. Craft moments of joy through design. Trend towards mirth before seriousness.
These standards should help answer most fundamental design direction questions, but here's an example for texture:
- As a first time Khmer student in Siem Riep
- I need to feel comfortable watching a video on my phone
- So I can know the app is worth my attention
- Guess less: Speak to the student, their teacher, and learn about their life and how the app fits their schedule and time
- Pen and paper sketch a UX flow that charges the user towards completing the "I need" goal with close to zero friction, people first for the whole journey.
- Build with accessible practices, to make a prototype of this function in a simple framework, test it immediately with a colleague or friend
- Do something else for a while, be healthy, and sleep on it.
- Come back the next day, tweak it or throw it out, give it another go, test it again with a friend, because you're building art together, not satisfying a brief.
- Test it with the student, or a good analogue. Test it again with someone else. Think through the ethics and impact of this design decision before committing code.
This example of a feature build process is more hands on with humans than the average geekery, because we have to work across cultures and geography by default.
If the systems and processes aren't available to get this hands on with people, make them happen! Right now! Have some patient impatience for delivering now, considering the long term, nurtutred relationships required to keep things sustainable.
Most design is 'designer done' when it's 80-90% finished and basic user needs are met. Go the extra mile by checking and rechecking with humans. This extra time, love and attention is only possible if we build fewer features overall.
Reinvent as few wheels as possible, use existing (simple) frameworks:
- Bootstrap 4 as a basis for the app, because it's simple and because Will D is embarrassingly old-school;
- SCSS!
fit_ is the namespace preface for everything:
.fit_btnis the special flexbox buttondata-fit_foois used to attach JS events, i.e.$("[data-fit_foo]")
P.S. put all your data-fit_foo_bar='blerp' at the END of elements.
.fit_foofor everything.fit_foo .subclassfor anything that cascades. We should never set a class for.subclassin this case, only ever.fit_foo .subclass- Leave bootstrap variables as they are.
The SDLC of the backend follows the structure of the frontend and the business as a whole; open source by default, declarative, version-controlled, and utilizing existing tools where possible.
- Diagrams errywhere so the system can be analyzed from multiple perspectives
- Model our data flow/information heirarchies
- Model the interaction between different users and our services
- Model our data flow/information heirarchies
- Compliance is a state of being
- Our code should match what exists, and constantly run checks to ensure that state is real
- SOC 2, ISO 9001 shouldn't be scary words
- Automate all the things
- API-based, creating multiple, versioned, medium-sized HTTP-driven services
- Serverless (if possible) on AWS
- Like a SquirrelBin https://aws.amazon.com/blogs/compute/the-squirrelbin-architecture-a-serverless-microservice-using-aws-lambda/
- Keep each customer's data separate at the database level (compliance!), and in the right region (GDPR!), and enable end-user data purging
- Like a SquirrelBin https://aws.amazon.com/blogs/compute/the-squirrelbin-architecture-a-serverless-microservice-using-aws-lambda/
- Find a naming scheme for services and stick with it
- Keep it readable; we may come and go, but the services will remain
- Encapsulate things like Wistia with a facade so it's not hard to switch out if necessary
- Diagram it first, throw it away, diagram it again, and turn that into code
- Probably in Python
- Service size should be medium-small; we don't want 20 microservices to load a page. Maybe 2 or 3.
- Don't call other services directly; you're talking to other services, not A Lambda Function (unless it's a data pipeline of some sort)
- Ideally public, Git driven, and collaborative
- Written in Terraform, ideally with PR-based infrastructure (via a tool like Atlantis) https://youtu.be/TmIPWda0IKg?t=61
- Utilizing AWS native DNS, CDN, and multi-region tools to conform to data privacy regulations
- Cutting edge but not bleeding edge; able to replace technologies (and methodologies) without great pain if they don't meet our needs
- Copious telemetry and monitoring to make sure the system works
- Copious logging to facilitate debugging and alerting
- If we would like to know, notify; if we need to take action, alert heinously
- Tag, tag, tag resources for security, cost management, and searchability
- Using this guide for readme Markup