December 5: Final project deliverable due
December 1: Client Demos, Team Advice in Ford ITW. Demo Times
November 30: In-class demos, client advice writing task.
November 18: Iteration planning with clients! Saturday 11:00am Ford ITW
November 10: Iteration planning with clients! Friday 10:30am Chambers Hall (Foster St), lower level
November 9: Ionic testing activity
November 4: Iteration planning with clients! Saturday 11:00am Ford ITW
November 2: Purple / Yellow team demos. Client project demos.
October 27: Meet your clients! 10:30am Ford ITW
October 26: New Team Meet and Prep
October 26: Final Team Project Demo: In-class app demos and wrap up discussion.
October 17: Google visit
October 9: Start of weekly coaching meetings and Retrospective reports
September 26: First demo!
September 21: Hybrid setup report and four-panel storyboard.
September 19 Day One -- What each team needs to prepare for the first day of class!


TTh 11am - 12:20am


Tech M164


Chris Riesbeck


EECS 394 Mobile Web App Tips

This course is not about programming per se. It's about software development issues and practices that transcend specific platforms and application types. That said, there are certain technical tips, particularly on the web side, that can make a big difference in building robust applications quickly.

Make your page standalone

Both iOS and Android support web pages that can be put on the homescreen like an app and run full-screen without browser chrome. It requires some planning on your part, a few lines in the HEAD of the HTML, and some icons.

If you haven't done it before, here are some helpful resources:

A good book on building mobile web apps, with details on both the design and the use of JavaScript and AJAX for interactivity is Build Mobile Websites and Apps for Smart Devices by Castledine, Eftos, and Wheeler.

Be RESTful

Here are some simple ideas for how to design the API (application program interface) for your web app. These are based on the REST theory for what made the web simple, robust, and so dramatically scalable.

Postpone Implementing Login

Many apps maintain user-specific information. Many students therefore assume that they have to implement user accounts with

This is a big mistake. Implementing login is high effort and low value.

You can easily implement user accounts and user-specific data without any of this, using RESTful URLs that contain the user's ID. This lets you skip all these problems with almost no coding effort.

To give someone a personal account with your application:

Look at A unique emailable URL is all they need to give you to run your own screensharing session.

This approach can be easily made more secure later. When you're ready, add code for

What is REST?

Roy Fielding in his doctoral dissertation defined a pattern for web services called REST (REpresentational State Transfer). REST is commonly misunderstood as being about URLs. Most of the theory is actually about content types and the proper use of HTTP headers. The big ideas are:

Since browsers traditionally only supported GET and POST, POST is often used to mimic PUT and DELETE, i.e., anything with side effects on the server.

Fielding's ideas inspired a number of modern web frameworks, including Rails and Django. Note that early versions of some of these frameworks got it wrong and had to be revised, e.g., Rails and Django's REST framework 2.