Week 01

01-28-2015

Overview/intro
What you should already know
HTML Forms
Design as a Liberal Art

Welcome

If you haven't looked at the course overview or met me (Kirk) yet, check out the course overview. The material for this course was created by Artie Kuhn. For this class, I have decided to remove most of the online discussion portion of this class so when Artie refers to this in his videos, you can disregard it. I want us to be engaged as a class and want you to be able share your ideas in a less rigid way than having required blog-type posts with required feedback. I'm not saying that there is anything wrong with that, but I would like to see how it works out in a less structured way. Ultimately I want you to be able to create well designed dynamic web pages using PHP and a database that will use Responsive Design (i.e. mobile friendly). Watch the following two videos introducing the course and walking you through the syllabus.

Introduction a (watch this video)
Introduction b (watch this video)

Next, watch the HTML and CSS refresher video below. Note: If you're not comfortable with HTML and CSS, this might not be the class for you. Reach out to me if you think you're in this camp, we might be able to work something out.

What tech you need to know a (watch this video)

Expanding on this, here's a brief refresher on HTML forms.

What tech you need to know a (watch this video)

The files for both of these are available to be downloaded.

If you're not comfortable with basic, traditional design principles like color, type and layout, you may find these lectures from my IMS254 course helpful. Note, if you are comfortable with these, you can skip these (although it never hurts to get a refresher).

Typography Basics (watch this video)
Color Basics (watch this video)
Color Basics (watch this video)
Color Basics (watch this video)

Design

This class is about advanced interaction design. Design has grown up and transformed in the last century. It started out as a craft of just doing (being able to typeset and whatnot) and has grown up into a way of doing and thinking. Read an article about the role of design today. Consider if you agree that design is a liberal art (something that exists across multiple disciplines) and consider if interaction design is any way more "liberal art" than previous forms of design.

http://www.huffingtonpost.com/jon-kolko/design-liberal-art_b_2427295.html

Assignment

Week 02

02-04-2015

Interaction Design - What's the Problem
Web Servers
xAMP

Introduction

Last week, we saw the beginnings of what will be a pattern for how this course is structured. Part of the week will be spent understanding a principle of interaction design and part will be spent learning a new bit of development nerdiness. Throughout the semester, these two will dovetail for a project where you’ll apply both and then split back off.

This week, we’ll be looking at goal-oriented interaction design and setting up a web server on your local computer.

Interaction Design: What's the Problem You're Trying to Solve?

Last week, we saw that design has evolved away from being about colors, shapes and layout. Different design researchers define design in different ways. For instance:

Besides being a little sexist (I’m looking at you Papanek), design researchers agree that, at the core, design is about solving problems. The readings from last week called them "wicked" problems, ones that span across multiple domains and ways of thinking. Papanek’s definition as well as Buchanan’s article from last week are explicit (and the others above are implicit) in that design is not for a small subset of professionals. Design is not merely the domain of "graphic designers" or "industrial designers" or "fashion designers" or "interior designers" or even "interaction designers". Barnes/Morley/Sayers state that "design activities range from cooking a meal to composing a symphony, from designing to satisfy our own needs and desires to designing for a commercial market" (2012).

So, how do we apply the design process to the web? How do we go about solving complex interaction problems? Solving design problems for posters or books or toasters or cars is complex, but a fairly straight-forward process. We’ve seen posters before. We’ve read books before. We’ve used toasters before. We’ve driven cars before. Innovative digital products, by definition, are new kinds of things that provide new ways of doing things. Things we haven’t used before. So, the design of them, by definition, will be both complex and ambiguous. We live in an era of transition, we’re moving from not having ubiquitous access to digital tools to having ubiquitous access to digital tools. During transitions, ambiguity is the name of the game. I’ve found it helpful to look backwards to another time of transition in order to help make sense of our current time. Read the following blog post to get a sense of how a previous generation dealt with a transition from one medium to another:

http://aims.muohio.edu/2012/02/06/digital-incunabula/

What I find fascinating about the incunabula is that it lasted so darn long. A generation to come up with the idea of page numbers! Imagine a book without them. Feels…well…wrong doesn’t it? I believe one of the primary challenges of design today is not to merely figure out the unique problems that interaction design presents, but to speed up the rate at which we figure out those problems. So, how do we speed this up? Research into successful innovative products show us that there are two key factors in the development of innovative products: 1) cross-disciplinary thinking and 2) a focus on the real problems that need to be solved. Read the following blog post that tracks the development of the mouse and the graphical user interface (GUI). As you read it, consider how each team that worked on the mouse and GUI approached these two factors. How did having a cross-disciplinary team and a focus on end users impact the development of the Macintosh vs the Lisa vs Xerox’s Alto vs the development of the Engelbart’s NLS?

http://aims.muohio.edu/2011/10/27/the-mouse-and-wimp/

Now, as we discussed last week, we have the cross-disciplinary thing down. If you look at the course roster, we’re filled with cross-disciplinary folks. The remaining task is a focus on real problems or as Matchett says in the quote at the start of this lesson the "true needs". Getting to the heart of the "true needs" is surprisingly tough. We bring all sorts of baggage and assumptions into a project.

This week’s readings are from an interaction design classic that had a huge impact on the interactive product development world. Visit the library’s website (http://lib.muohio.edu) and search for "About Face 3: The Essentials of Interaction Design" by Alan Cooper. From the catalog listing, you will be able to read it for free on Safari Books Online (follow the link to "Connect to Safari Books online" in the library’s catalog listing). Read the foreword and chapters 1, 2 and 4.

Once you’ve read the chapters, consider the following questions:

Interaction Development: Web Servers

Up until this point, all of your web development work has probably been using the following workflow: build some HTML on your local machine, test it in a web browser and upload to a web server to share when done. This is a fine work flow if want your web pages to be relatively static. However, if you want your system to remember what a user did or enable a user to add content or change things, you’ll need a web server. Here’s an overview video of how all of this works.

Intro to Servers (watch this video)

We call the combination of a web server, a scripting language and a database technology a “technology stack”. There are many different “technology stacks” out there. You’ve probably heard of some of them. PHP, Java (not to be confused with JavaScript, that’s something entirely different), Ruby, ColdFusion etc. all web scripting languages. They’re often paired with a database. The most common database language is SQL. SQL comes in two dominant flavors: Microsoft’s SQL and MySQL. Microsoft’s SQL is proprietary and closed-source, but comes with different flavors that are tailored to different needs. MySQL is free and open source, but requires a bit more finagling. Another popular free database is PostgreSQL (which is the one that Kirk has been using for many years). It is very similar to MySQL. For this class, we’ll be using MySQL. For our web scripting language, we’ll be using PHP. PHP is well established in the marketplace and having it on your resume is a great thing. It too is free and open source. Finally, our web server will be Apache. Now, here’s the awesome thing. Apache running PHP and MySQL is an extremely common technology stack. So common, in fact, that it has a clever name “xAMP” where “x” stands for whatever platform you’re running it on (WAMP for Windows, MAMP for Mac, LAMP for Linux, etc.), “A” for Apache, “M” for MySQL and “P” for PHP.

Even better than a clever name is that it’s exceptionally easy to install and well supported by the open source community. For the technology side of things this week, you’re going to download and install your own copy of xAMP on your machine. You’ll get it running, put up a test PHP page (we’ll get to MySQL later), take a screen shot and email it to Kirk. If you encounter problems, email me. The videos are couple years old and the xAMP stuff looks a little different now but they are still similar enough that you should be able to get it up and running. That's a problem with making a video of a web page (or putting something in print), as soon as you finish it, the material could change. Welcome to the land of IT (Information Technology).

Getting Started with xAMP (watch this video)
Getting Started with PHP (watch this video)

Assignment

Week 03

02-11-2015

Project One introduced
Databases
PHP

Introduction

By now, we have covered a fair amount of ground. You have a little tiny web server running on your laptop (isn’t it cute?). You’ve written your first bit of PHP. You’re starting to wrap your mind around design and how it’s a strange discipline that crosses multiple domains. You’ve also, hopefully, agreed that at the center of design’s pretty little heart, it’s all about solving problems. Hopefully, I’ve also convinced you that solving problems is easier when you have seen the problem before, but much harder when you have ambiguity. Unfortunately for all of us (or fortunately if you thrive on challenges), we’re living in an era of interaction design where the lines aren’t already drawn and all we have to do is color them in. Instead, we live in ambiguity. Folks are inventing stuff all the time that are new things that provide new ways of doing things. And that means we need some tools to help us make sense of ambiguity. We saw how the early printers made sense of their medium (slowly) and how cross-disciplinary teams that look at the real needs of users make faster progress (like the development of the mouse and the GUI). You saw how Cooper argues that one of the key tools that help us make sense of ambiguity is understanding our user’s goals and developing a goal-oriented product.

Last week, we were heavier on the design of things and a little light on the nerdery. This week, we’ll shift weight back and be heavier on the nerdery than on the design principles. We’ll also kick off Project One.

Interaction Design: Aggregating Knowledge of the Customer

In many ways, successful product design is about knowing what problems your product needs to solve. The readings from Cooper were all about getting your mind wrapped around problems folks have. At that stage, any good research effort would expose way more problems than you typically can solve. Another key to good product design is about compromises. You can’t solve all those problems, so which ones do you want to solve? Now, at this point, we could make a giant list of problems and point at the ones we want to try to solve. However, that’s focusing on the problems rather than on the goals of our users. So, what we really need to do is figure out which of our potential customers are we willing to tick off.

A while ago, Apple launched the iPad. Loads of folks laughed at it and said it was just a “big iPod Touch”. Today, the iPad rakes in more cash for Apple than all of the major PC manufacturers combined make off of laptop sales. Why did folks laugh at it? Because it said “no” to a ton of things. “No, you can’t have more than one window open on screen at once”. “No, you can’t run programs that are on your Mac”. “No, you can’t have access to the files and folders on the device”. No, no, no, no. However, by making those compromises, Apple was able to scale the total size of the operating system way down so that they could have lower storage requirements on the device so it was more portable. It also meant that developers could easily port their existing iPhone apps over to it. And it also meant that that pesky file system that was constantly confusing non-tech users simply didn’t exist. You see, Apple was willing to tick off power-users and technologist in order to win over the masses and craft a beautiful product. Contrast this with Microsoft and Windows 8 and Surface. Microsoft’s whole deal is that Windows 8 allows you to have a tablet with no compromises. However, by saying “yes” to all of those things the iPad says “no” to, they’ve created a frankenproduct that’s struggling in the marketplace.

37Signals is a hugely successful web-based software company. They often argue that all great software is “opinionated”. I think so too. Apple’s iPad is opinionated. Love it or hate it, you know what Apple thinks is worth doing with it. If you don’t like that, they’re more than happy for you to buy a more expensive Mac laptop from them. A handful of years ago 37Signals put together a handsome book called “Getting Real”. Next time you have a spare couple of hours, I’d check it out. Recently they’ve posted the whole thing for free (awesome) on their website. Go ahead and read all of chapter 4: Priorities. It’s a brief read, will probably feel more like a handful of blog posts than a chapter.

http://gettingreal.37signals.com/toc.php#ch04

Welcome back. So, how do we go about figuring out what the big idea is and who our customers are? Well, Cooper has some ways of figuring that out. He calls them Personas. Hunt down About Face 3 again on the library’s website and read chapter five, “Modeling Users: Personas and Goals”.

Hopefully that went well. So, now we have a little model we can follow. First, we do on-the-ground ethnographic research with potential customers to determine their goals and problems they have in accomplishing those goals. Next, we aggregate those goals and problems into straw-man characters that we call “personas”. THEN (and this is the important part), we recognize which of those personas we are willing to lose so we can delight the others.

Project One - Phase One: Research, Personas and the Big Idea

So, reading about doing research and creating personas is all well and good. But, you don’t really know anything until you actually do it. Next week, I’ll introduce the full scope of Project One. However, this week, I want you to get started by doing research and creating personas. Project One is about creating a functioning proof-of-concept of a web-based tool that helps college students get things done. Here’s the kicker, it needs to be about helping them get only one kind of thing done. That could be a tool that helps them get homework done. It could be a tool that helps them quit smoking. It could be a tool that helps them go from being a couch potato to running a marathon. It could be a tool to help them read Moby Dick. Whatever it is, it needs to be a large goal (“get homework done”, “quit smoking”, “run a marathon”, “read a long book”, etc.) that has multiple steps (“day one to run a marathon: stretch, run for 5 minutes, walk for 3, run for 5 minutes, walk for 3, run for 5 minutes, cool down, go home”, etc.) that the user needs to track over time. Those steps should be pre-defined by you. So, in other words, if someone wanted to stop smoking, you would pre-define how they should go about doing that for thirty days into discrete steps. You prescribe what they have to do. They use your tool to track their progress.

Once you have the large vision of what kind of product you’d like to build, you need to do ethnographic research to determine the needs of your potential customers using the techniques Cooper outlines. If you need a kick-start, I’ve linked a set of the design firm IDEO’s common research techniques to unstick your brain. This research does not need to be incredibly complex or time consuming. Talking to five to eight friends who would be in the target audience of your app for five minutes each is good enough. Visiting a location on campus that’s relevant to your product (like the Rec for a marathon training tool) and watching for problems is good too. Document this research through photographs and take copious notes. From that research, craft at least three personas in Word or something similar. One persona should be a primary persona, one a secondary or supplemental persona and one should be a negative persona.

Cooper doesn’t get too specific about the format a persona should take. Every team I’ve been on has crafted them slightly differently. For this class, I’d like them to be formatted like this:

So, for instance, let’s say you chose a stop smoking tool. In your research you may have found any number of reasons folks want to stop smoking and problems they have with stopping. Some may want to stop because their significant other is fed up with it. Some may want to stop for health reasons. Some have tried to stop before, but they have friends who smoke and the social pressures were too great to really stop. Others may have tried to stop before but lost sight of the health benefits of stopping. You’d craft these into personas. Finally, for the final step of this phase of the first project, is to outline what the big idea for your tool is. Write why your tool needs to exist in less than twenty words. That’s the Big Idea. So, for instance, a quit smoking tool’s big idea might be “Everyday, comfort detoxing-smokers by reassuring them that the side effect they’re experiencing is normal.” Or, it might be “Everyday, encourage ex-smokers by showing them how much healthier they are that day.” Or, for instance, your marathon training tool might be “Provide simple, but progressively harder, training regiments to transform a couch potato to a marathon runner in six months.”

Interaction Development: Databases

Last week, you set up a server (congrats) and did a tiny bit of PHP. This week, we’re jumping into the deep end of databases. Brace yourself. It’s, honestly, not that hard, but it does require thinking with a part of your brain you may not be used to. Watch the following four videos.

Week 3 Intro (watch this video)
MySQL 101 a (watch this video)
MySQL 101 b (watch this video)
MySQL 101 c (watch this video)

PHP Troubleshooting & Deprecated Messages

This section was added after finding some descrepancies/changes from when Artie recorded his videos and what we're using today. Hopefully these videos will help you in case you get stuck. I should also mention that when I hit a road block, I typically turn to Google searches for the answer. If I don't find the answer in about 15 minutes or so, I put it on the back burner and come back to it later. If I'm still having trouble, I turn to a friend; often times another pair of eyes working on the problem is all you need. For our class, you can turn to me for help. Also, don't sell your classmates short; you should be able to turn to them as well.

PHP Troubleshooting (watch this video)
Deprecated (watch this video)

Assignment

Week 04

02-18-2015

Tog’s Laws
Wireframes and Mockups
PHP & MySQL and CRUD

Introduction

Alright, this week is a fun week. Things we’ve covered will all start coming together this week. For the design half of everything, we’ll finally get to what everyone thinks of as “design”: making pretty things. For the development half of everything, we’ll finally get PHP and MySQL to really start talking to one another and doing some slick stuff.

Interaction Design: Jobs to be Done, Tog’s Laws & Reality Disruption

Cooper’s thinking around understanding the problem your customer is trying to solve is a key one. His promotion of personas really put a dent in the interaction design world. However, he’s often criticized for not going the next step. How do you make the jump from Big Idea to something that works? There are a handful of different ways to go about this, but the most common in digital agencies and digital product development are wireframes and mockups. If you’ve taken IMS222 or IMS257, you’re already familiar with these concepts. You’ll need to be comfortable with the basics of Illustrator and Photoshop. If you need help, let me know and I’ll point you to some resources.

How do you really narrow down what you need to create? Time to look back at your personas. What problems do your personas have? Clayton Christensen, a Harvard Business School prof and researcher, calls this kind of thinking “what’s the job to be done” by your tool? What is it “hired” to do? Listen to the following podcast. Warning, it’s about an hour long, but it’s quite good. You can bail out after the first 28 minutes or so.

http://5by5.tv/criticalpath/19

Welcome back. Alright, so now you know how to narrow down to what problems really matter. Now it’s time to start creating those artifacts of design. At the heart, wireframes are just crude sketches of what you want to do. They’re the bones of a design. Mockups are fake screen shots of what the thing will really look like. They’re the muscle and skin. Please search for the excellent book HTML & CSS: Design and Build Websites by Duckett on the library’s website. Again, you’ll be able to read it for free. Read chapter 18.

Craft your first pass at a series of wireframes on paper. Show a handful of pages of your concept. Get specific. What buttons go where? Then get brutal. Which buttons don’t I really need? What features can you skip and leave for future generations to worry about? Etc. Iterate and revise. Once you have wireframes you’re happy with, create them in Illustrator. Just black and white is fine. Why? Well, normally this would be when I tell you that you should take your wireframes and test them with your users. However, we don’t have time for that. Or I would tell you that nice Illustrator-based mockups are good for clients because they look professional. Well…we don’t have a real client for this project. So, what’s the real reason to do them in Illustrator? Frankly, I believe that you’ll discover loads of mistakes when you move from paper to Illustrator. You’ll realize you still don’t need some functionality. Or you’ll discover that the text is too small. Etc. Moving to Illustrator is one more step towards making your design real. Duckett has a sample wireframe or two, but Google around a bit to see more.

Once you have the wireframes, it’s time to start mocking up the actual interface. This is where colors, fonts, etc. come into play. This stage can be rough for you if you’re more of a developer than designer. That’s okay, just remember that the technical stuff is going to be cake for you, but rough for the designers in the class! Create your mockups in Photoshop or Illustrator. They can be as tall as you’d like, but the number of pixels horizontally should be in the 900-950px range.

As you’re designing, it’s worth recalling Tog’s First Principles of Interaction Design. You can view them here. If you’ve taken IMS222 from Artie, you’ve heard him go on and on about Tog’s First Principles. Here’s the story. Bruce Tognazini (his friends call him “Tog”) was at Apple from 1978 to 1992. Back before there was such thing as a Mac, Apple release the Apple ][. In the early days of personal computing, every program had a different look/feel and user experience. You launched a program, you were in a completely new world. Scroll bars might be different. Buttons looked different. Etc. Soon after being hired, he set to work to change this at Apple. He published The Apple Human Interface Guidelines which became the starting point for user experiences being developed for Apple. Around the same time, he wrote a program that was distributed on every Apple called “Apple Presents…Apple”. It was a brief tutorial on how to use an Apple machine. What’s funny is that Tog wrote it as if all the programs on the Apple ][ would look the same. So, early adopters received their computer, ran “Apple Presents…Apple” where they see Tog’s designs for how the interface will work (lifted from this Interface Guidelines) and just assume that’s how all the programs will work. What’s great is that developers just kind of fell in line and release programs that used Tog’s interface. After the Mac was released and Jobs was forced out of Apple, Tog became in charge of the interface for the Mac and was responsible for many interaction patterns that we still use today. So, read his First Principles and consider your wireframes. Do they break any of his principles? If you think you have his First Principles down pat, prove it by downloading this self-check quiz. Read it, can you answer all the questions quickly?

Project One - Phase Two: Wireframes and mockups

Use paper to create a series of wireframes that shows how your tool will function. Your wireframes should cover at least three pages of the tool. Note, some of you may want just one “page” for your tool. That’s okay, just show it in various states in your wireframes. Once you’ve sketched them and are happy with them, craft black and white versions in Illustrator of all three pages. Be sure to iterate and clean them up as you move from paper to Illustrator. Next, build yourself a mockup in Photoshop to scale (remember, no more than 950px wide). Just one. You don’t need to mockup every page, just one. Looking at the wireframes of multiple pages and the mockup of one should be enough for others to get a sense of where you’re driving the bus.

Interaction Development: PHP & MySQL and CRUD

Watch the following three videos on how to take our simple to do list and make it actually start working.

PHP Forms and MySQL CRUD a (watch this video)
PHP Forms and MySQL CRUD b (watch this video)
PHP Forms and MySQL CRUD c (watch this video)

Assignment

Week 05

02-25-2015

Iteration
HTML and CSS

Introduction

We’ve covered a lot of ground in the first four weeks. Week five is about bringing it all together and building something great. I don't know if you realize it, but you have been working on Project One this whole time. This week you will put the finishing touches on your ToDo list and as a colleague of mine says, "make it pretty". You know all of the nuts and bolts and have a functioning ToDo list already, this week, make it look nice. You will demo your functioning ToDo list (i.e. Project One) to me on 03-04-2015 (whenever we have our 1:1 set).

Interaction Design: Iteration

I am not a car guy. However, this post about the Porsche 911 shows the value of something really important: iteration. Doing something over and over again until it’s perfect.

http://37signals.com/svn/posts/3426-the-porsche-911-an-ode-to-iteration

The value of iteration cannot be emphasized enough. In design, rarely is your first direction the right one. It’s annoying, but it’s important to iterate. To give you a sense of Artie's work and iteration, take a look at two process books Artie put together while working on his MFA. They outline his process for two projects. Note how much iteration went into each.

narrativeAndProcessBook_ApliaText.pdf

narrativeAndProcessBook_customCourseware.pdf

What do you do with feedback? Well, it’d be simple to go in one of two ways: accept it all or deny it all. This binary way of thinking is a common mistake for folks crafting digital products. Remember back to why you have personas, you can’t create something that makes everyone happy. That includes making making me happy. In the end, you need to take the feedback you’ve been given and filter it through your personas. Pushing back on feedback rather than blindly taking it all in is a sign of maturity in a designer. Would the items you’ve heard make sense to each of them? Would it help, hurt or is it neutral to your personas? Only the ones that are helpful should be considered.

A good way of processing this is to make a simple list. List all the feedback you’ve received. Go through it and rate 1-5 how helpful each item is to each persona. 1=hurtful, 3=neutral, 5=helpful. Write a note each to each item to justify your decision on that feedback. In a design agency, you’d bring this list with you to when you physically discuss the items with the stakeholder who requested the change. Rather than approach it as a “no” on things you don’t think should be done, you should approach this as an opportunity to dive deeper into what they’re asking. In my experience, when saying “no”, I discovered that the problem the person was trying to solve needed to be solved, I just didn’t like how they wanted me to solve it. I’d often go back to my office and think about alternative solutions then propose them back to the stakeholder. In many instances, the solution we arrive with was a great one that really improved things.

To drive this home, read chapter six from the Getting Real book.

Project One - Phase Three: HTML and CSS

It’s tempting to jump in and build an entire project from scratch. You may also feel overwhelmed by the idea of actually doing everything you said you wanted to do for this project. Instead, start small. Start simple and slowly build out.

Many developers want to start with the nerdery. They want to start putting together the database and the PHP and whatnot. In general, avoid this temptation. Instead, if you start with the user’s view first, you’ll often discover things that need tweaking. Once you’re done with the user facing stuff, you can dive into the database and whatnot.

So, start with plain-Jane HTML and CSS. Handwrite what you’ll imagine would come from a database. Have it all hardcoded into the HTML. Then, once you’re happy with the user’s view, start breaking it apart and build out the components that need PHP and MySQL.

We have kind of done this backwards. What gives?! You needed to learn how to do the database stuff and you already have a basic understanding of HTML and CSS. So here's the deal, you can (re)start your project from scratch with HTML and CSS and use the database stuff that you learned (copy/paste from your .php files that you created so far) or you can tweak your existing code to make it look pretty. Ultimately you need a functioning ToDo list that looks nice and does what the user expects it to do (achieves the goal, whatever goal you want it to achieve). I'm really looking mostly for a useable system that doesn't make me say "yuk".

Note that Project One is due 03-04-2015. Schedule your time knowing that we will return to our usual set of videos next week as you wrap up the project.

Assignment

Week 06

03-04-2015

Reality Distortion & Progressive Disclosure
Project Two introduced
Exporting tables

Introduction

We’re moving on to Project Two. This week, we’re light on the technical development so you can focus on getting your concept for Project Two down solid.

Interaction Design: Reality Distortion & Progressive Disclosure

Recall Engelbart’s NLS which we looked at back in week two. Engelbart’s demo introduced all sorts of concept that we still use today: the mouse, hypertext even screen sharing. Before we go on, you may want to look back at the blog post I wrote a while back and watch a few minutes from that demo on YouTube.

http://aims.muohio.edu/2011/10/27/the-mouse-and-wimp/

The Mother of All Demos (watch this video)

What’s insane about Sutherland’s work is that it was written for a 1950’s era computer which was the size of a room. Today, I can do the same thing (and more) on my phone!

On one hand, we have Engelbart’s highly complex, but powerful, system that used a completely new “language” of clicks and key presses. On the other, we have Sutherland’s intuitive interface without any real “power” (meaning it could only do a few things). What needed to emerge was a fusion of these two. An interface that was intuitive built on top of a powerful system.

You’ll also recall from week two that Xerox took Engelbart’s ideas and commercialized them in their Star. The Xerox Star was, for the most part, a commercial failure. However, Tim Mott’s back-of-the-napkin sketch of an office metaphor provided a way forward. By creating the first interface driven by windows, icons, metaphors and pointers, users could quickly understand what was possible and how to go about working. Watch this great video from Xerox introducing the Star.

Xerox PARC Demo for Apple (1979) (watch this video)

As mentioned in the video, Xerox allowed Apple access to their technology early in the development of Apple’s Lisa (which also bombed) and Mac (which, clearly, dented the planet). Why did Engelbart's concepts fail? They "worked". They were "powerful". Why did they fail? Because they were simply too complex. Developers often think something is "done" when it simply works. We've all used software like this. Timecards. BannerWeb. Niihka. These things work. However, they're a pain to navigate. They're hard to understand what you can do. Contrast this with the success of the original Mac. It not only worked, but delighted the user. It was easy to understand. The office metaphor was the bridge between Engelbart's powerful but complex system and what we needed, a powerful but easy to understand system. This is not an example of "dumbing down" the system (which is often the accusation of developers when designers get involved). This is an example of caring more about the end user than you do about the technology. Which, ultimately, matters more: bytes or humans?

Watch this brief video of Bill Verplank discussing interaction design. Consider how, using Verplank’s terms, the graphical user interface allows users to understand how you “do” something and impact how it “feels” and how the user “knows” where to go next. As you're watching the video, think about how the office metaphor fits into this framework.

Interaction Design (watch this video)

Think about one aspect of the Macintosh or Windows OS leveraging each of Verplank’s terms. Examples include the “trash/recycle bin”, “folders”, “files”, etc. Again, consider how the graphical interface helps you understand how you do something, how it impacts how it feels and impacts how you know how to do something next. Also consider how hardware impacts this cycle. How does the mouse or keyboard impact this loop?

Today, we’re in the midst of a similar sea change in interaction design to the one introduced by Mott’s back-of-the-napkin office metaphor. The pointer and mouse has been replaced by the user’s actual body. In Kinect-like gestural interfaces, the user’s limbs become pointers. On tablets and smart phones, our fingers literally press interface elements. With Siri and voice activation, our voices power the interface. It’s interesting to note that our means of interacting with computers are becoming increasingly personal. My actual finger represents “me” on my phone (vs. a pointer represents me on my laptop). My voice can ask for driving directions. Our interfaces themselves are also becoming more personalized. For instance, Siri “knows” who my wife and children are. Netflix “knows” which movies I like.

During times of transitions like these, designers need to help users along. One of the ways we can help them understand Verplank’s three things (“do”, “feel” and “know”) is by using metaphors. Mott introduced the metaphor that dominated interaction design for 30+ years. Folders. Files. Trash cans. Pointers. Icons. Windows. However, as we move into a post-WIMP era, users still need metaphors to help them make sense of what they can do with an interface. They also need metaphors to help them feel comfortable doing it. They also need metaphors to help them know how to navigate the interface.

So, in touch-based interfaces like those found in iOS (iPhone/iPad) and Android, gestures are the metaphors. Pinching along sliver of glass becomes a metaphor that means “zoom” or “close”. Another metaphor are those in the aesthetics. By using visual elements from “normal” life, users can become more comfortable. The more strange or uncomfortable the interface, the more users need this to help them feel like it is normal.

For instance, on my iPhone, I have an app called “Find My Friends”. It’s, essentially, a stalking app. It allows me to track the location of people who have approved it. So, for instance, rather than my wife needing to call me while I’m driving home to see how far away I am, she can launch “Find My Friends” and it will display a map with my location on it. Check it out on the App Store:

https://itunes.apple.com/us/app/find-my-friends/id466122094?mt=8

This makes many users uncomfortable. So, to make it more palatable, the designers have added rich corinthian leather textures throughout. It’s argued that this makes this strange thing feel more more comfortable. This use of textures and other visual elements to help bridge the cap between real work and digital world is called “Skeuomorphism”. Skeuomorphism is nothing new. In fact, if you recall back to week two, the blog post on the incunabula had examples of early printing press works “faking” previous media in order to make them feel more palatable. Fake woodgrain on station wagons was an example of skeuomorphism. My digital camera playing a “click” sound that mimics the sound of a shutter opening when it takes a picture is another. Proponents of using skeuomorphism in our designs argue, essentially, that it helps manufacture a sense of “normal” to make something that’s not normal seem more accessible. Here’s an excellent blog post that introduced this concept of a “Normalcy Field”:

http://urbanhonking.com/ideasfordozens/2012/06/24/designing-for-and-against-the-manufactured-normalcy-field/

Now, those that don’t like skeuomorphism consider it window dressing. Style for the sake of style that gets in the way of a user “knowing”. Here’s a good summary of the problems:

http://www.macworld.com/article/2023604/apple-and-the-future-of-design.html

Really, at the heart, things like metaphors and skeuomorphism are about finding a balance between Verplank’s do, feel, know. They can help with each, but can also get in the way of each. Take, for instance, iBooks (Apple’s iPad e-book reader):

Note there’s a “stack” of paper on the left edge and right edge of the screen. This is to help us feel like it’s a “normal old book”. It’s supposed to assist with that normalcy field. However, it confuses the “knowing” the underlying structure because it never gets smaller or larger as you read through the book. If you’re on the first page, there’s a stack of pages of the left. If you’re on the last page, there’s still a stack of pages on the right. Users can literally push their finger onto the glass and move it to “turn” the page. The page turn animation assists with the “feel” by making it feel more real. However, once users are cranking quickly along in a book, the extra two seconds the animation takes gets in the way of the “doing”.

Think of other examples of skeuomorphism. How does it balance do, feel and know? Do you think visual metaphors like skeuomorphism are good or do you feel like we don’t need them anymore?

Project Two - Phase one: What’s the Big Idea?

Project Two is a website optimized for mobile devices. It will know where the user is and present information relevant to the user based on their location.

Machines knowing where we are? This is not normal. This makes people uncomfortable. Part of this project will be to figure out ways to help the user with this disruption in the “normalcy field” so they’re more comfortable and trusting of the site.

For this stage, use the techniques from last class to come up with a Big Idea for a mobile website that leverages the user’s location to deliver content about information in the Oxford area.

Now, you could do something “normal” like provide restaurant information, information about the campus, etc. However, I don’t want that. I want something that disrupts the “normalcy field”. For instance, what might a location-aware diary/journal look like?

Sketch wireframes (on paper is okay - but you will email me the wireframes) of your Big Idea. The wireframes should be of at least three pages (ideally more like five) and be fully realized. It should be clear how one navigates the site. Push the concept almost to the normalcy field breaking point. Wherever possible, you should use real images and sample text rather than filler text. I expect you to spend most of your time for this class this week on iterating and perfecting these wireframes.

Development

We’re really starting to have some powerful stuff now. However, how do you move it around? Now we’ll switch gears a little bit and do a brief overview of the process of getting your apps off of your computers and ready to load onto a server.

Exporting Tables (watch this video)

Assignment

Week 07

03-11-2015

Mockups and Mobile
CMS

Introduction

This week, you should be knee deep in Project Two. You should have a solid concept and your wireframes should be complete. We’ll be diving right into building your first content management system (a tiny one) on the tech side. On the design side, we’ll be pretty light, looking a little more into wireframes.

Interaction Design: Mockups and Mobile

Why mobile? It’s pretty obvious to technologists that mobile is the future of what we do. In 2010, more smartphones were sold than laptops, desktops and notebooks combined. There’s a great little book called “Mobile First” published by A Book Apart. I’d recommend you check it out. Here’s a small quote from pg 8:

Obviously, mobile is a big deal and it’s not a fad.

It’s important to note that people aren’t simply putting down laptops and switching to mobile devices. They’re actually changing they’re usage patterns. Read this, slightly dated, article on when folks are using their smartphones:

http://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/

There are two ways of dealing with mobile devices. One is to build device-specific apps and sell them through app stores (like Google Play and Apple’s iOS App Store). The other is to make our normal web pages work on mobile devices. Now, I won’t get into the future of the web and whether or not apps are going to replace the web (hint: I don’t think they will). BUT, with just some simple changes to how we approach designing websites so we embrace mobile devices, we can see huge improvements in user engagement. Here’s a great summary of some up-to-the-minute happenings around the web when it comes to designing sites to work well on mobile to tablets to laptops to desktops (called “Responsive Web”):

http://www.lukew.com/ff/entry.asp?1691

In the coming weeks, we’ll recap responsive web (in case you hadn’t been exposed to it in IMS257 yet). For now, however, there are some simple things you need to know.

First, while Android represents a larger population of smartphones, iPhones represent a more engaged user base. Analysis of usage on both clearly shows that many Android users use their phones as “dump phones” with nice screens. While I am an Apple fanboy, I don’t mean this to disparage Android devices. Many are great. However, it’s pretty clear that, at least for now, iPhone users use their smartphones for browsing more. So, designing first for iPhone is probably a smart idea.

Second, while there is a growing ecosystem of tablet devices, it’s also pretty clear that the iPad is really the only tablet we need to worry about (for now). Why? Because most of the installed tablet user base is iPad and non-iPad tablets aren’t quickly catching up.

So, that means we’re good to go if we primarily design with the iPhone and iPad in mind. Usage of the iPad from landscape to portrait mode varies, but most folks browse their iPhones vertically (in portrait mode). Until recentlyy, the width of iPhones over the past few generations has remained unchanged (the newest ones are taller, but not wider), that means we can design for the width of an iPhone fairly confidently. Unlike iPhone, the iPad product line is a bit more fragmented (first two generations of iPads were lower resolution and Apple recently introduced the iPad Mini). The good news is that folks have already done most of the work for us when it comes to getting some nice templates to start from. Artie's favorite templates to start building mockups with are available here:

http://www.teehanlax.com/downloads/

Once you have your hands on those templates, choose if you want to focus on your Project Two concept for smartphones or tablets (either is fine) and get to work crafting your mockups.

Project Two - Phase Two: Mockups

Use the provided templates to create a series of mockups. It should be noted, that typography, color and layout should be fully fleshed out at this stage. Be sure to review the Project Two problem statement. Let me know if you have any questions.

Project Two: The Problem

Mobile devices (smartphones and tablets) have surpassed traditional computing sales. Not only are they more common, they’re also intensely more personal. They’re computers you carry everywhere. The really are personal computers.

This project will leverage the highly personal nature of these devices and create a website that will know where the user is and present highly personalized information relevant to the user based on their location. Without care, this would disrupt the “normalcy field”, but careful consideration of the user experience and the user interface will help users be more comfortable with the tool.

Examples include a diary/journaling web-based app that keeps track of the geolocation of entries, a score keeping app used to log real time results from games, etc.

Project Two: The Process

You have already developed a concept/The Big Idea and wireframes.

Next, you will begin technical development and mockups of the tool. You will receive instructor feedback and iterate based on that feedback.

Ultimately, you will implement (in HTML, CSS, JavaScript, PHP and MySQL) your solutions. These solutions should be specifically designed for mobile devices. The solution must use a device-specific API (such as geolocation) or a service-based API (such as Yelp).

The solution must leverage the use of a light-weight content management system (CMS) for backend administration. NOTE: this means that there could be two different aspects of the site. First, there would be a backend administration aspect that allows “editors” to post information. This would not be optimized for mobile. Second, there would be the customer-facing aspect where those posts would be displayed.

Project Two: The Schedule

Development

This week, we’ll build the foundation for a light-weight content management system. Note: Artie encountered some technical problems with the videos this week, so the first video ends rather abruptly. I (Kirk) also added a "PHP with Kirk" video following Artie's 4 videos. The PHP with Kirk video walks you through the CMS project but done as Kirk would do it. Some things in the PHP with Kirk video will look a little different than Artie's because it was done more recently. For example, tinymce looks and operates a little bit different. I also show you how I recall the same page to do inserts (etc.) instead of using redirects; one way isn't really better than the other, they're just different.

CMS a (watch this video)
CMS b (watch this video)
CMS c (watch this video)
CMS d (watch this video)

Using the techniques discussed in the CMS videos, you should build your own lightweight CMS. At the very least, it should support users posting titles, rich text for copy and images.

You've asked for it, here it is, PHP with Kirk. I work a little different than Artie does. Here is some bonus material to see how another programmer writes code. Enjoy.

PHP with Kirk (watch this video)

Assignment

Week 08

03-18-2015

Documentation
APIs

Introduction

This week, I’ll be sending you individual feedback on your mockups. After this week, you’ll have all the PHP and MySQL knowledge you’ll need. We have gone through most of our video tutorials for the semester. For the remainder of the semester, we’ll have one-on-one meetings (as needed) for progress checks, with relatively light readings online. You will be spending most your time working on Project Two and Project Three.

Documenting Your Process

Documenting how you got from A to Z is an important part of interaction design projects. Documentation takes many forms. It might be formal technical documentation that allows someone to pick up the project after leave. It might mean a set of formal design guidelines. It might be simply the archived list of completed tasks. As we enter the final phase of Project Two, I’d like you to begin documenting your process. One way I have documented the process is using comments in the code (PHP) using /* comments go here */ at the top of the program. I have also written out the functionality of the program in english before coding it using //comments. Try either of these methods as you work on this project.

Development

What's an API? http://www.quora.com/APIs/In-baby-language-or-laymans-terms-what-is-an-API

Now, for the most part, there are two common types of APIs, device-specific and service-oriented. Device-specific APIs come in two flavors:

  1. ways for you to get information from a device without needing to know HOW it gets that information
  2. ways for you to store or display information on a device without needing to know how it does it

An example of the first device-specific API type is location services. Different devices determine your geolocation in different ways. My phone uses a GPS. My laptop triangulates based on wireless networks it’s picking up. But, as a developer, I don’t care how it’s finding out where I am. I’m simply saying “find where I am” and it responds with longitude/latitude coordinates. An example of the second is HTML5’s support for drawing vector graphics in the browser. Different browsers on different platforms might technically be doing different things to draw a line from point A to B. However, as a developer, I don’t care how it’s doing that, I just know what I need to tell it to make it happen.

Service-oriented APIs are a little easier to understand. Some web-based services really rely on users to generate content. In order to encourage that, they often make it possible for folks outside of the company to use their resources in order to drive content creation. An example is a service like Yelp (if you don’t know what Yelp.com is, go check it out really quick), Twitter and Rotten Tomatoes. Having user-generated content is key to the survival of these services. So, rather than force everyone to use their website or their app, they open up their services to outside developers. These outside developers can then use these services however they want to. Twitter caused a pretty big outrage when they changed the rules of their API after a thriving development community had built up around them. Here’s a post from the weeks following the announcement that sums up what went down:

http://www.marco.org/2012/08/16/twitter-api-changes

While the drama over Twitter shows that it’s risky to base your business on APIs controlled by someone else, APIs are an incredibly powerful tool. If you can get the hang of working with them, they’re insanely useful in a variety of domains. In Artie's information and data visualization course, a handful of students who have taken 422 or who have self-taught APIs are building incredible things by simple use of APIs.

As the problem statement states, you’ll need to incorporate at least on API in Project Two. That might just be JavaScript’s location API. Or, it might be a service-based API. Watch the following video where I walk you through how to use JavaScript’s location API and combine it with Yelp to build a small tool that displays restaurants near your current location. All of my source files for the project are available below (after the video).

Location and Yelp API (watch this video)

No need to turn any exercises in this week. However, it would be foolish not to play around with this stuff and get familiar with it before you get too deep into Project Two.

yelp.zip

sampleYelpResults.js

Now for some bonus material from Kirk. The following videos were created to help you with Project Two and Project Three. I also wanted to give you a some more tips on how I program in PHP (PHP require and substring fun). I have also received some questions about relational databases. This class was designed to address I/O (inputting and outputting data into/from a database) but the class generally only deals with one table at a time. The "Relational Databases" will show you how to create multiple tables and query those tables. The video is somewhat long (sorry) and it takes a deeper look at databases. I will also give you my code (BonusMaterial.zip) so you can play around with it as well.

Using MAMP with Other Devices (watch this video)
PHP Require and Substring Fun (watch this video)
Relational Databases (watch this video)

Now for my code that was discussed in the videos:

BonusMaterial.zip

Assignment

Week 09

03-25-2015

Spring Break

Assignment

Week 10

04-01-2015

Project Two work week with 1:1 progress check

Assignment

Week 11

04-08-2015

Project Two work week with 1:1 progress check

Project Two - Final Review

Project Two has been a long trip. I’m really excited to see what each of you have to show. While we’ve had one-on-one meetings for the last few weeks, many of you haven’t seen one another’s work at all. Let’s change that! This weeks assignments are relatively light in order for you to have time to wrap up Project Two and spend time providing feedback to your peers. Get together with at least 2 other students in the class (in person or in Google Hangouts) and show them what you have done. Listen to their feedback; it is always interesting to hear a new point of view. Remember, when giving feedback, be nice.

Coming up - Project Three: Groups

We will be working in groups of 2, 3, or 4 for Project Three. If there are folks from the class you’d really like to be on a team with (or those you’d prefer not to be on a team with), email me before 04-15-2015 and I will take those requests into consideration.

The tentative groups are:

Assignment

Week 12

04-15-2015

Wireframes

Introduction

At this point, we’ve covered loads of ground. Your PHP and MySQL skills should be rounding out. While you might not be able to write PHP/MySQL code completely from scratch, you should be able to pull things together from previous weeks and resources online.

Wireframes

We studied wireframes already in previous weeks. However, I think it’s easy to loose track of their importance to the ideation process. It’s also to confuse them with crude sketches. Professional-grade wireframes are refined and capture the heart of a site. Since we’re about to start on the final project, one that will require collaboration, I think it’s a good idea for us to revisit them.

To begin, read the following articles:

http://blog.45royale.com/post/31822274280/wireframing

http://uxmag.com/articles/shades-of-grey-wireframes-as-thinking-device

Essentially, wireframes serve four purposes:

  1. They allow you to get a concept out of your head so you can start thinking visually. Which elements work? Which ones don’t? What buttons are you missing? Etc.
  2. They allow you to collaborate with others. Having a physical thing others can react to (beyond just concepts) allows ideas to build on one another.
  3. They are a way for you to do some initial usability testing. Showing others and asking them which area they would expect to represent which bit of functionality allows you to do a quick gut check of a concept.
  4. They allow you to document. Doing pixel-perfect Photoshop mockups is a time suck. Refined wireframes take a fraction of the time and allow you to start documenting the needs of a product to allow development to start. Often, developers are working from wireframes while designers are busy fleshing them out, then they both meet to implement the final “skin” of the wireframes.

To build on this, read chapter seven in User Experience Re-Mastered. Again, it is available online through lib.muohio.edu.

Assignment

Week 13

04-22-2015

Project Three introduced
Design Thinking & Mobile
DeviceOrientation API

Introduction

This week is a fun one. We’ve rounded third and are headed for home, so now we get to jump into some really slick stuff. While PHP and MySQL are incredibly deep topics, we’re going to table them for now. Instead, we’ll be looking back to the basics of the web: HTML, CSS and JavaScript. If you’re not terribly comfortable with JavaScript, reach out to me a lot over the next few weeks, I don’t want you falling behind. We’ll also be starting the final project this week. The final project is even more open-ended than the last one and I’m excited to see what you guys come up with. As always, start into the material early and work on it often throughout the week. Reach out to me if you encounter problems.

Design Thinking & Mobile

It’s clear that mobile is the future of the web. For years, Facebook seemed to avoid mobile. Their strategy seemed to be to focus on ways to get folks to do what they normally do on the Facebook desktop site on their phones. It kind of failed miserably. Since the early days of Facebook, they hired designers, developers and product folks from the most successful mobile apps. The most high-profile was their acquisition of Instagram for a billion bucks (yeah, billion). However, they also hired away designers from Apple and some of the most well-known iOS app developers and designers. Clearly, they were gearing up for something big. Many nerds assumed this was because they wanted to launch their own phone. Instead, they’ve leveraged Android to create a layer that replaces many of Android’s key features with Facebook Home. Also note that rather than put Facebook on a phone (which has been their strategy up to this point), they’ve taken the individual bits of Facebook and rethought how they should be configured on the phone. For instance, the scrolling photos on the lock screen replace the timeline.

It’s also interesting because it’s built on top of Android. Google has always promoted the openness of Android. However, Facebook has now used that to build something that keeps Google away from what they need. Google built Android in hopes to get more folks to use the web so they can track more folks and then sell advertising to those folks. Now, Facebook gets that data. Facebook gets to sell those ads.

For an excellent analysis of this, check out http://www.asymco.com/2013/04/10/making-rain/

Now, why does this matter to us (besides “mobile is cool”)? Use the design thinking techniques we’ve looked at. What is the job-to-be-done by Facebook? Does that job make sense on a mobile phone? How would you expect consumers to react? Will they trim their friends list so they don’t see the dog picture from a random kid from third grade on their lock screen? Would they use certain features more on a phone than on a desktop? How would those personalized ads be received? How would you expect Google to react? If Facebook is fishing further up stream, what can Google do?

Project Three, Teaming Up and The Big Idea

For Project Three, you’ll be working in small cross-disciplinary teams. The most successful digital product teams work across disciplinary boundaries to solve problems and build products that delight customers. Up until this point, you’ve all been working in individual silos. No more! Instead, you’re going to work in small teams to develop a web-based app for a tablet or smart phone. I will assign these teams soon.

Here are the guidelines for the teams:

  1. You will meet together for at least two hours a week either using Google Hangout or in person.
  2. You will meet with me as a team when needed. All team members should be present.
  3. As a group, you should discuss your “Resources/Processes/Values (RPV)”. RPV is a framework that Clay Christensen uses to discuss companies. I, personally, also think it’s a great way to capture information about members of a team. For Resources, list what kinds of resources you have access to. This is both hardware (PC/Mac, tablet, scanner, etc.) and skills relevant to this assignment. For Processes, capture what you know how to do with the Resources you have. For instance, an individual might have skills like “good at typography” and “good at layout”. A Process that they can do with those skills might be “I can design Photoshop mockups of interfaces really well”. Finally, Values: what do you care about? Christensen makes a key point on Values: if you’re not spending your time or money on something, you don’t care about it. Stuff that isn’t necessarily directly related to this class is also good to know. Things like, “I care about music, I play bass in a band” is great as well.
  4. All members will carry their own weight. I have an incredibly strong distaste for folks who rely on others to do their work for them. As such, a large percentage of the grade for this project will be based on your work with your group. If you don’t pull your own weight, your peers will ding you. I will notice in weekly check-in meetings. Your grade will be much worse. Play nice, work hard and you’ll do fine.

Once I’ve assigned teams, you’ll need to meet for at least two hours. Come to this meeting with a handful of concepts to present to your team for the project. The guidelines for the project are relatively simple.

Project Three Guidelines

  1. It must be a tablet or smartphone web-based app that is friendly with the iPad/iPhone. I’m sure there are other devices that have nice tech specs out there, but if you want to develop something for the masses, the iOS device is the only one that matters. I know many folks don’t have iOS devices. No worries. If you have a Mac, you can do your testing on the iOS simulator that is baked into XCode which is a free download from the Mac App Store (and also comes free on the installation discs on older Mac OSs). If you have a PC (or have a Mac, but want to test on the physical device), you can borrow an iPad from the AIMS office. Talk to Kate and you’ll need your Banner ID. If you’d prefer to do a short-term lend, the libraries (King in particular) also loan out iPads.
  2. It must make use of at least one HTML5 API exposed through JavaScript. This could include (but is not limited to) the Geolocation API and the Device Orientation API (mentioned later).
  3. The app must be goal-oriented. The app must have a reason to exist. Users must have a goal to accomplish. This could be anything from a game to a weather app to a cooking training app to a productivity tool. It is not a neat tech-demo that looks cool but doesn’t let your users do jack squat. I’d encourage you to leverage the values you have learned about to help drive what the app should be about. So, for instance, if other people in your group express interest in music, maybe you could do some sweet music-related thing.
  4. It must be finished. Whatever you turn in must be finished. Not just ideas, but really working.
  5. It is the culmination. I expect it to leverage many of the things we’ve discussed. This includes the design aligning well with Tog’s Laws. When appropriate, it should leverage PHP/MySQL. If appropriate, it could leverage a service API like Yelp or Rotten Tomatoes.
  6. So Project Three is a lot like Project Two, but in this round you are working in groups, which creates a unique dynamic. Part of your grade on this assignment will be based on how well your group works together.

Start off by introducing yourselves. As you’re meeting with your team, discuss everyone’s concepts. Meet in a room with a whiteboard and everyone should bring their own whiteboard marker. Do not sit down. Everyone should stand and huddle around the whiteboard. Share your concepts. Hopefully, one concept will emerge as great ideas. Discuss them, refine them, etc. Sketch what the app could look like on the whiteboard. If you sketch it to scale, you can get a sense of how big the buttons will need to be for touch, how much you can fit on screen, etc.

Then, as a group, write up The Big Idea in the format discussed in previous weeks (starting in week three if you need a refresher). One individual should note The Big Idea; maybe even capture photos (camera phone is okay) of the whiteboard.

Once your team has the concept down, you should assign tasks to individual team members to complete by next week. Examples might be “design user interface mockup in Photoshop” or “build sample code of using CSS3 3D rotation working with the accelerometer”.

As a team, go ahead and schedule a thirty minute time block with me next week. When we meet, I’ll want to review your Big Idea, sketches and progress on tasks. I’ll want to know what you intend to work on next and I’ll coach you in helping you refine the concepts down to something manageable based on your team size and time left over.

Finally, we’ll all meet physically (for those of you in Oxford) during the last week of classes to see what each group came up with (this is when the assignment is due).

Development: Using the DeviceOrientation API

We’re almost done covering all of the development topics we’ll cover this semester. This week, we’re going to look at another JavaScript API. We’ve already covered the Location API. This week, we’ll look at device orientation. This allows us to know when the device is being moved, what angle it’s being held at and which direction it’s facing. As you can imagine, it’s pretty great.

Artie put together a demo of the key stuff available at http://artiekuhn.com/classes/mu/422/deviceorientation. It won’t look to slick unless you’re using a mobile device that supports this stuff (in other words, don’t bother trying it on your laptop). Before you dive into the code, skim this post to get the idea:

http://www.html5rocks.com/en/tutorials/device/orientation/

Code for Artie's device orientation site

Okay, now jump into the code. You’ll notice that we can measure changes in position, angle and orientation (north, south, etc.).

This week, take the code and do something cool with it. It doesn't matter what it is. Maybe you make your own compass that always rotates to north. Or what if you used the 3D transformations in CSS3 to make text on your screen skew as you turn the device? Or what if you went less literal and made the screen turn red when the device is being shaken and fade to a nice blue when things calm down? Whatever, just kick the tires and make something neat. If you need a primer on CSS3, check out this little cheat sheet Artie put together a while back:

http://artiekuhn.com/html5/css3InHTML5.html

The (no-longer tentative) groups are:

Assignment

Week 14

04-29-2015

Project Three work week with 1:1 progress check

Assignment

Week 15

05-06-2015

Project Three (due 05-06-2015)

Assignment

:-)