Android Tutorial Design Principles

Document Sample
Android Tutorial Design Principles Powered By Docstoc
					This document is an informal overview of the thoughts and decisions made during the construction of
the Android Tutorial as originally designed by Lawrence Angrave and Alex Loeb for the Spring 2010


         Our process began with an enumeration of any and every topic we could think of which was
related to the development of an Android Application. This list was then divided into parts where each
part consisted of similar topics from the original list. Eventually we had divided the entire list into
several parts which mimicked the composition of an Android Application. Namely we had a part for
Activity related elements, inter-Activity/Application communication, data management, sensors and
peripherals, permissions and other configurations, UI (Layouts, Views, etc…), and a sort of macro level
view of the components of an Android application and how they fit into the overall OS. We then split
each of these parts (the above list is not exhaustive) into two sections: basic concepts or fundamentals
and then advanced concepts or topics.


         Once we had our content, or rather, more content that we could possibly handle, we sought a
method of presentation. We knew we had a single weekend to cover everything we could fit in, but we
quickly realized we would need to handle setup and install for all of the required tools if we wanted an
interactive tutorial. (We had decided this at the outset given the thought that a non-interactive tutorial
would not be able to sustain the interest and focus of the attendees given the breadth of material which
would have to be covered, even if only in a shallow format.) Thus we decided to hold a pre-tutorial crash
course in installing and configuring all of the tools. We would hold this session the evening before for a
couple hours to ensure that everyone who wanted to attend the actual tutorial could show up and
participate without any delay. Once we had our weekend laid out on a macro scale, we broke the day of
the tutorial down into sections. Our theory was to divide the entire day into 20 minute sections so that
we could have the most flexibility, but yet keep a rigid schedule. (This paid off more than we imagined.)
Given the early start time of the tutorial we hosted, we set up the first hour or so to be an overview of
the SDK and tools available so that those who chose to show up late would not miss the actual content.
Once we began the actual content, we decided on a structure where each session would be composed
of three parts: See, Do, and Review. The idea was that each session would be one hour long and each
subsection would be one 20 minute slice of the day. The See section would be a brief presentation of
the concepts and motivations of the topic, the Do section would then be a time for the attendees to
apply the concepts just presented, and the Review section would be improvised to either present
advanced material or address difficulties or problems encountered during the Do section. This flexibility
also turned out to be well worth it.

Putting it together:
         Once we had our content and our presentation format, we needed to put it all together. We
built a powerpoint presentation for each See section. We ended up with six total hour long components.
To provide context, motivation, and coherence to the entire tutorial, we took the Snake demo provided
by the SDK, stripped out the irrelevant parts, and then built an application around it which exercised the
concepts we wanted to cover. Once we had a complete application, we broke it apart into six parts
where each part focused on one of the six topic sets we had previously outlined. When we designed the
application, we made sure each topic was addressed twice, one to be demonstrated in the See section,
and one to be performed by the attendees in the Do section. We then created six different Android
projects where each project was a progression from the previous, i.e. we wanted to place all six projects
in a repository so that the attendees could download the project associated with the session being
presented. They could then add the code we specified to the project before downloading the next
project which would have all the changes we expected them to make already implemented so that
anyone who failed to complete the changes could still proceed using our provided code. Furthermore,
we would be able to only show the attendees the relevant code for each session along with code they
had previously been presented or written without all of the confusing code they would have yet to see.


          Given our six projects, our six powerpoints, and our breakdown for the schedule of each day, we
were set to go. During the day of the tutorial, most things went horribly off schedule, but we managed
to cover everything we wanted and the overall feedback was quite positive. What saved us was our
flexibility. All of our sessions seemed to bleed together, most of our time went to the interactive parts
and most of our presentations became informal announcements with a lot of repetition. In the end,
despite our emphasis on keeping things simple, we tried to cover too much too fast. The ultimate
consensus was that such a tutorial needs to be given in several smaller sessions and each of those needs
to have more explicit examples and time to grasp the peculiarities of developing an Android application.

Shared By: