Give this website a look:
Tiff Zhang's Start-Up Generator
Every time you click this link, it will generate a random, fake, start-up company website.
Here's a funny one called Youprogram: I guess this would be a start-up about bringing programmers to the outdoors where they can do team-building exercises next to nature, while still having access to outlets and wifi for their laptops?
Of course, none of these are "real" websites. Tiff Zhang is just using a random number generator, a long list of nouns and verbs, some stock photos and names to match, a few small icons, random bright colors, a few different English sentence templates, and the same generic Bootstrap layout. Usually this leads to a senseless (and often humorous) result, but every once in a while the random combinations come up with a realistic sounding business.
So, when we think about a Good (in the capital-G sense) design, are we talking about how the website looks good on desktop and mobile? how it loads quickly? how it is universally accessible? Along these "key metrics," the randomly generated start-up websites are all good.
But of course, none of them have any functions or information that meets the needs of any real business or real user base.
This is our last Lab before the midterm assignment. The reading for this Lab (the reading for weeks seven and eight) shifts away from HTML and focuses more heavily on the decisions we make of what to include in our websites.
When we get back from spring break, we'll continue learning about HTML and CSS, as that's the technology that allows us to build a website at all.
But my reason for covering "planning" right before break is that, during the break, we'll also introduce our Case Study project, where you will be asked to both plan and code a website. And since coding can take a lot of time, it's good to first have a clear goal of what you are and are not going to have in your design.
Making the decisions of what to include and exclude is the easy part. People (project managers) sometimes find that the harder part is communicating those requirements to their team of programmers. And although you won't have a team of programmers to do your bidding for this course, I've found it useful to document your thoughts as though you were writing them for someone else (or for yourself in the future after you've forgotten where your ideas came from).
Garrett gives us, in chapter four, some good general advice for how to write and use these "specs." If you haven't read it already, I refer to you the sections in chapter four titled:
Some of you ask a question along these lines in your journals last week: How do we know our users? How do we test (with real data and experiments) what we believe about our users?
Well, you can't know everything about your users. (And, in a Cynic or Skeptic worldview, you can't know anything for certain about your users, but Epicurus said that those Greeks were self-defeating with that sort of attitude.)
The Business Model Canvas (the technique used to explain the Pokemon Go business model) is designed to help us go about our business anyway. It works like this: you make an educated guess about how the world works; you design a prototype with that in mind, knowing that you aren't 100% correct; you test your assumptions of the world using that prototype; and you revise, each time moving further up from prototype to "real business," ending up with a business that is open to the idea of "adapting" to meet the shifting needs of your users.
In this approach, as well as in movements in software development dubbed "Agile" approaches, we prioritize getting something in front of real users. The sooner you can get feedback on your ideas, the better, the idea goes.
So, how can you actually gather that data?
The Preece reading focused on this. For the most part, this reading was a more in depth version of what Garrett was writing about. But in section 7.4, Preece lists a few ideas of how to gather data: "questionnaires, interviews, focus groups and workshops, naturalistic observation, and studying documentation."
In the modern world of the world wide web, we might be tempted to add A/B Testing to this list, though we could also consider that a more specialized (and automated) form of "naturalistic observation": You design your website so that it can "watch" how people use it for you, how they navigate from one page to another, what buttons they clicked to get there, how long they spent on each one, and how much money they decided to spend placing an order.
By "observing" your users in this way, you might notice that they are behaving in a way that is contrary to your expectations (educated guesses). So, you come up with a hypothesis, and test it.
For example, to test a hypothesis like, "a blue button would attract more customers than a red button," you would make a "B" version of your website and randomly send a small percent of your users there instead. Whichever version (the original or the experimental) does the best (makes the most money?), that's the version you keep.
But, this idea leads us to a new thing to consider when making web designs. So far, we've thought about our designs from the business and the user perspective. If we are also using the site to collect data on our users so that we can improve the site later, we have to think about our designs from the scientist perspective too!
Think not "What do we know about our users," but, "What can we learn about our users?"
To submit, write your responses to the following questions in a Word document, then upload it to Blackboard under this week's folder in Current Assignments.
Labs are due two weeks from when they are assigned, on Sunday at 11:59pm eastern time.
Labs are each worth 5% of your final grade. Scoring on your submission will be based on the following rubric:
0% - Student does not submit on time or submits plagiarized or unacceptable work. Double check that you have attached the right file, as usually students get zeros because they upload a previous week's Lab by accident.
1% - Student answers less than half of the questions with sufficient or accurate responses. Make sure that you are leaving yourself enough time to complete the Lab each week, as usually students submit incomplete work because they were rushed at the last minute.
3% - Student answers almost all questions with sufficient and accurate responses. If you encounter a problem or have a question about one of the questions, be sure to post in Ask the Instructor well before 24 hours before the due date, then continue to attempt to resolve the issue on your own while you wait for a reply.
5% - Great job, maximum points! The student answers all questions accurately and sufficiently, demonstrating the best of their ability.
Note, because Labs span two weeks' worth of reading, it is recommended to go through the Lab twice, once after the first reading where you answer everything that you can, then again after the second reading where you answer everything else.