SPECIAL TOPICS IN
Holistic Mobile App Development
for Android


Tuesdays 4:00–6:50 — Dane Smith 130

Prof. Patrick Gage Kelley

pgk @ unm.edu


Google Doc of App Stuff
Google Doc of App Demos

Blank Poster Example
Instagram Example


Schedule and Important Information
  1. Tuesday January 13
    Introduction

    Let's make an app real quick snap.

    Here are the slides I used that did not scare you away: slides (PDF)

  2. Tuesday January 20
    Feature Ideation
    MVPs: An Introduction
    Every time I come up with an idea to build an app, there is something similar already available. Should I still go ahead and build my app?

    3. Google Hangout on Funding Your Startup
    Tomorrow! google+ link

    Global Game Jam, Albuquerque Edition
    This event will take place January 23-25th and is a 48 hour game jam (for creating a game). Participation costs $5. More information at : facebook and global game jam.org.

  3. Tuesday January 27
    Paper Prototyping / Gestures + Interaction
    Paper Prototyping: An Introduction
    Really, the experts say do this.
    Literally 200 videos on Paper Prototyping

    Due in class: 10 Ideas
    You must turn in at the beginning of class: 10 ideas.
    *Each* idea should be of the form: App name, app description, three main features.
    For example:
    Camera Awesome: An app that helps you take more awesome photos. Features: takes photos, has awesomeize button, helps you compose photos.

    IF your app improves upon a category or type of apps, you must include at least 2 apps it is similar to and you must tell me how it is going to be better (cheaper, faster, new feature, simpler, better designed)

    IF you want to focus on games at least 7 of your ideas must be games
    IF you want to focus on non-games at least 7 of your ideas must be non-games

  4. Tuesday February 3
    Interface component concepts Part I / Our First App

    Due in class: 1 (Attempt) at a Useful Interface Component
    You must be ready to discuss/display:
    1 useful interface component that you have designed (on paper).
    This interface component should fit into one of your 10 app ideas for the previous week.
    You should explain why it is needed in the app, and how the interaction works.
    Work out the complicated bits.
    What's hard? What's easy?
    Where are points of possible confusion. What were alternate design possibilities you considered?
    What do other apps do, how do they differ from each other?
  5. Tuesday February 10
    Interface component concepts Part II / Our First App

    First Draft Full Application Proposal Due
    This must include:
    • App Name
    • At least one paragraph app description. Write this as you would a description in the app stores. Read other app store descriptions to get help on this.
    • An initial icon sketch
    • An initial feature document (we will refine this into a spec document later). This should contain a list of things you will need to implement for core functionality, but may include additional rounds of features that you could later develop after the app is functional.
    • An initial interface walkthrough. This must show each of the screens you are currently planning. These can (and should still be) hand-drawn.
    • If your app is similar to other apps provide interface screenshots of them, their description, and a link so I can explore them
    You *can* include more in this proposal, the more you include the better off you will be!
  6. Tuesday February 17
    Application wireframes / UI Design / Android Layouts
  7. Tuesday February 24
    View components work day
    No class, PGK in a Carolina.

    8. Class will be held as a work section. PGK will be absent but TAs Laura and Ramon will be present.

  8. Tuesday March 3
    Initial Spec Documents / Android View Components

    Initial App Spec Documents Due -- Delayed
    View Components Due

    Android View Components
    Google Doc of App Stuff
    The only thing you should turn in is a link to your view component online.

    Your Android View Component must be turned in through github.com (or a similar alternative, if say, you have a love affair with BitBucket). They do not need to be public-public and you can sign up to get free educational private repos here : education.github.com.

    I am not going to give you guidelines on what must be turned in, that is you do not have to properly componentize your submission (such as through Maven Central, etc.).

    Below are some examples of Android/iOS Interface Components for you to mimic, this is the type of thing I am looking for:

    Android Process Button (a button, with a progress meter in it)
    https://github.com/dmytrodanylyk/android-process-button

    Flat Button (a customizable flat style button)
    https://github.com/hoang8f/android-flat-button

    SlidingMenu (Play Store Demo)
    https://github.com/jfeinstein10/SlidingMenu

    Material Menu
    https://github.com/jfeinstein10/SlidingMenu

    Frosted Sidebar
    https://github.com/edekhayser/FrostedSidebar

    Parallax Effect
    https://github.com/ccarnino/StratosParallax


    Thursday March 5
    Satellite Coffee Work Session 2pm-6pm (Satellite on Central/Harvard across from campus)
  9. Tuesday March 10
    Spring Break

    Wednesday !!! March 11
    Satellite Coffee Work Session 2pm-6pm
  10. Tuesday March 17
    Initial App Spec Documents Due

    These documents should be migrated from your app proposals to an online form (preferably github or google docs or some other editable doc, etherpad, etc.)

    For many of you I asked for more details and versioning than I saw in the first app proposal. Please put these online, with any modifications you might make, and we will refine together.



    Thursday March 19
    Satellite Coffee Work Session 2pm-6pm
  11. Tuesday March 24
    Paper-prototypes results due
    Paper Prototype Results Due
    This is now due Thursday March 26th (ideally) to the google doc

    Using the paper prototypes you have already created and the progress you have made on your app, you are going to run a user test of your paper/digital prototypes and do at least one round of revision. You will also need a short script to help guide people through your app, or the parts of your app you want to test. This script is most likely a short description of what tasks you will have users do with the device, and the specific sequence of actions that the user should take with your prototype to achieve those tasks.

    Part 1 You should put your paper prototype (you can use some digital components if you believe they will be helpful) in front of at least three and preferably more users. Audio or video recordings may be helpful. You should turn in two things for Part 1, 1.1 The script that you are using to guide people through your app. 1.2. A short report describing the user results.

    Part 2 Next you should modify your paper prototype (or digital components) to try to fix the problems or confusion you observed in your user study. For Part 2, you should turn in a short summary of what you changed.

    Part 3 Now, show three or more people your refined materials. Ideally you will use the same script (if there were problems with that please note it in part 2). For Part 3 you should turn in another short report describing the user results, and if you were able to fix any problems (and what new problems you created!)

    For creating your short report on what you witnessed, you want to think about your users in terms of subjects in an experiment. A very thorough approach to this can be seen at this action form: http://www.cs.cmu.edu/~bam/uicourse/UARTemplate.doc. While you can use these, you should at least include a list describing each test subject's relevant characteristics, perhaps including age, gender, occupation, level of technical sophistication, previous experience with similar apps (if they have previously existed) or experience with the subject matter of your app. To preserve your testers' privacy, it's not necessary to include the subjects' actual names. You will also, at least, want to record the answers to the questions asked in your script.



    Thursday March 26
    Satellite Coffee Work Session 2pm-6pm
  12. Tuesday March 31
    Work day, additional topics as needed
    Final Spec Documents Due


    Thursday April 2
    Satellite Coffee Work Session 2pm-6pm
  13. Tuesday April 7
    Privacy/Advertising day

    Thursday April 9
    Satellite Coffee Work Session 10am-1pm (DIFFERENT HOURS!)
  14. Tuesday April 14
    In class critique of COMPLETE apps

    Complete, Functional Apps Due


    Thursday April 16
    Satellite Coffee Work Session 3:30pm-6pm (DIFFERENT HOURS!)
  15. Tuesday April 21
    Final work day
    No class, PGK in Korea.
  16. Tuesday April 28
    App polishing day Please link your icons! (latest Thursday at noon)

  17. Tuesday May 5
    Final Show: EPICENTER @ INNOVATE ABQ, 3:30-5:30pm, Tuesday May 5th

    poster

    Tuesday May 5 (at show): Poster Due
    Tuesday May 5 (at show): Demo Due

    Friday May 8: Complete, Functional Apps Due (in repo)
    Friday May 8: Digital copy of poster due (to google rep)

    PGK End of Semester Office hours:
    Thursday April 30: 11am - 2pm (at Satellite Coffee on Central across from campus)
    Friday May 1: noon - 2pm (in Farris 301B)
    Monday May 4: 11am - 1pm (in Farris 301B)
    Monday May 4: 1pm - 5pm (at Satellite as above)



Holistic— "The real entities of the material world must, like organisms, be creative, self-transcending, functional. They must be Holistic unities." British Weekly, Jan 1927

Mobile Apps— "Right now we have been and are building the future of computing, and what it means to be connected to the internet, for the vast majority of human beings." Dieter Bohn, The Verge

Course

This is an advanced studio course in human-computer interaction, interface design and arts, and mobile application development. While the course will focus on the process of creating, designing, and building mobile applications, topics surveyed in the course will be tailored to student interests, and may include: user interface design, usability testing, paper prototyping, touchscreen design, typography, graphics, feature prioritization, specification documents, release cycles, methods of funding, privacy, advertising and other product concerns.

The course is designed around a small number of projects and a final, public capstone. Students will work across disciplines, solving problems of designing and building useful mobile applications.

Enrolling students are expected to have demonstrable programming skills. Students are expected to have Java language and programming experience at the level of CS251. Recommended: Java at the level of 351, experience with graphics/UI design, experience with software frameworks, software engineering. The course be taught with Java as the in-classroom language using the Android Development Tools (ADT) package. The final projects may be created using other languages, frameworks, and libraries.

Non computer scientists, be prepared to do some actual programming.
Computer scientists, be prepared to do some creative work.

Graduate students should register for section CS 591 and undergraduate students for CS 491.

Grade

Schedule

A broad outline of the course:

Learning Objectives