Programming for Online Prototypes

A hands on introduction to building online products and services through code

© 2016. All rights reserved.

  1. Home
  2. Creative Projects - Proposal

Creative Projects - Proposal

tl;dr; Prepare a short but detailed proposal that outlines the idea you'd like to work for the final project.

Creative Projects: Proposal

This is the first step on your creative project. You’re asked to come up with a compelling, interesting or creative idea for a bot you’d like to build by the end of the semester.

The proposal itself should be posted to your student page (either inline or as a link to a sub-page that you create).

Choosing a project

Take a look at some suggestions in the main project description!

Writing your proposal

Requirements: The proposal should be at least 200 words describing the idea, why you want to build it and what it would do with a maximum of 500 words. Feel free to sprinkle in some images, links to relevant related projects or designs which have inspired your approach.

I’d highly recommend you have a clear explainer of your proposed app. A really effective way to do this is to try to explain it as a tweet. If you can communicate clearly in 140 characters, then you’re in good shape.

Then, put some meat on the bones and give more details of the what, hows and whys of it. A good proposal should give a clear but succinct description of the web application you plan to build. You should address the following:

  • What is it? What does it do? Give a succint description of the things the app will do and why it’ll do them? Note: It’s perfectly OK to have something that isn’t useful, a creative exploration, playful approach or rediculous experiment is just fine.
  • Why are you making it? Is there a specific need or purpose? Why do people need to know about this thing?
  • What platform is it for? Will it be a SMS, Twitter, Slack, Telegram or Alexa bot?
  • Who will use it? Who is your audience and how will it serve their needs?
  • How will it work? What things might it do to interact with them? Will it notify them of stuff, will it email them, will it gather data online?

An alternative might be to include a simple scenario (a short imagined narrative) of how they might interact with your application. A scenario is a story of expected use and it can be a great way to communicate your idea effectively.

Submitting your Proposal

Either edit the ‘README.md’ in your Student Folder or create a new file called ‘FinalProject.md’ use this to add all documentation to.

These files are written in Markdown pages (see this cheatsheet too)

You can edit this in one of the following ways:

  • You can edit it raw within your text editor of choice
  • GitHub provides an online inline editor - visit the repo, open the file, and click the edit icon in the toolbar (right hand side).
  • You can use an online tool like Dillinger or StackEdit to develop your document, and then copy and paste to your repo.

Example

Bad

I’m going to build a bot that’s creative. It’ll find interesting text from online sources, edit them and then share them on Twitter. StockBot will alert you to interesting facts about stocks you care about. It’ll monitor stocks and then send you a message when there’s a change. When it changes then the user can manage their investments and change them as they need. It’ll give them the information they need to do this. It’ll also send a weekly summary to them and give them a report on what’s changed with their stocks.

Why are they bad? Not enough information in either of these to see. They don’t mention what platform will be used or where the data might be collected from or what might be presented to the user. A general rule of thumb: think of the proposal as you writing an assignment brief for yourself. Could you implement it immediately based on the information you’ve provided?

Good

Example 1

Summary: NutriBot is a meal tracking application that’ll help you log your meals by SMS and give nutritional breakdowns for each entered meal.

Details: The application is designed to help dieters or fitness enthusiasts keep track of how much food they’re eating each day. It’ll work through Twilio and a user will be able to send a photo of their meal by MMS along with a description. This will be kept in a database. It’ll let the person enter some information about the meal too but ideally would be automatically analyzed. Nutritional information about the meal (fat, carbs, protein, etc.) will be stored too. Each meal will be compared to the user’s daily goals and they’ll be updated on their progress. At the end of the week, they’ll also get a summary report of each days outcomes. Ideally the app will have some notifications to remind the user to log their meals if they haven’t in a while too. The app will be really friendly and give the user encouragement and reward them with fun experiences when they hit their goals.

Example 2

Summary: ‘Landed in Pittsburgh’ is a friendly Twitter bot that’ll welcome people to the city as they arrive.

Details: Building on the work of Jer Thorp’s Just Landed, I plan to build a Twitter bot that will look for people tweeting ‘Just landed…’ with a geolocation at Pittsburgh International Airport. It’ll send them a little greeting that’ll welcome them to the city and a suggestion of one thing to do while in Pittsburgh. If there’s time I’d like to let them interact with the bot to handle responses or requests for more information.

Scenario: Jane has packed her bags and is looking forward to a weekend away with her best friend Mary Beth. After a long day at work, she grabs a cab to the airport and embarks on her flight to Pittsburgh. Moments after touch down and as soon as she cabin crew allow phones to be on, she’s whipped hers out and excited tweets: “Just landed in Pittsburgh for a weekend with @marybetha #excited”. As she’s walking through the terminal, she sees a few likes of her tweet and a new reply … From @WelcomeToPittsburgh saying “Welcome to Steel City, Jane. And check out the Gallery Crawl tonight… https://trustarts.org/event/”. She clicks the link and sees it’s right up her alley and forwards it to Mary suggesting it for tonight.

Before you begin.

Keep the following in mind:

  • Keep your scope narrow. Your bot shouldn’t be a swiss army knife; it should do one thing incredibly well. Be focused and maintain a lean but well executed outcome. It’s easy to add in lots of bells and whistles; try to avoid this temptation.

  • You don’t have to build it all. For example you might say that user signup/onboarding is out of scope for this project and you’ll just assume that people are in the database and prebake that in. If this gives you room to sweat the details on the actual implementation that’s great.

  • Don’t just design for when it works; design for errors too. With text entry lots of unexpected things can happen. We’ve all had the experience of being on the phone with an automated system and it being incredibly frustrating because it doesn’t understand us or do what we want. Design for these moments. Figure out ways to know when you’re failing and do something unexpected, suprising or graceful in those moments.

  • Keep input/interaction to a bare minimum. If you find there’s a lot of input needed, you’re doing it wrong. If you find there’s step after step needed to get where you want to be, you’re doing it wrong. Simplify and be creative.

That’s all a very roundabout way of injecting a Deiter Rahm’s quote

Less, But Better - Dieter Rams' Principles of Good Design

Want more context?

Read these