Part 1 of this Google+ Interaction Design looked into the user interaction for moving some Auto Backup photos into a new Album. The post went through the process, looked at some possible issues with the flow, and proposed some slight changes that hopefully could make the process a little more logical for the user.
Part 2 was going to extend this analysis to the Sharing part of the process. However during the actual investigation, the playing around with Google+, it seemed that a more holistic reworking of the interaction was really what was needed. In general the Google+ interface was found to be non-minimalist, and to use a coding term, was a little spaghetti like. It was also a struggle to fully understand the logic underpinning some of the UI behavior.
This post starts off the reworking process. This is very much a work in progress. Hope it ends well :-). Continue reading
I find that I semi-regularly use the Google+/Android Auto Backup of photos, and then share via a private Google+ link that I email around to family/friends.
The Android/mobile side of things is simple… basically just take the photo, and then when back on Wifi and charging, the images will be uploaded to Google+. However each time I go through the Google+ process of adding the files to an album and sharing, I find myself getting confused, and hitting dead-ends each time :-(.
So I thought it was time to try and understand where I was having problems, with inspiration being drawn from the lecture series on Human-Computer Interaction.
To simplify the write up, I was going to break the process in two, firstly adding the Auto Backup files to an Album (Part 1), and then the subsequent sharing of the Album (Part 2). However after starting on Part 2, I decided that I needed to broaden the scope a little, and consider more of a general reworking of the Google+ Photos interaction. If you want to jump ahead, you can go directly to Part 2 (work in progress though).
(Part 1) Adding Auto Backup Photos to an Album
Successful Use Case Flow
First step in the process was to document a successful use case flow. A simple UML type use case diagram was used. Continue reading
With all previous rwmthings apps, the design process grew from the bottom up. Basically playing with the underlying technologies, then massaging the results into a UI that somehow displayed the content :-).
For MoodUp, a more user centered design approach was used, inspired by both the 2013 Google I/O talk Structure in Android App Design, and the online course Human-Computer Interaction.
The following shows a basic story board for the app flow as it stands today. Note that during development, the app morphed a fair bit from the original ideas…
Finally released the new MoodUp app.
Allows you to share you mood, and receive comments/feedback from other MoodUp users…
Check it out here, or over at the Play Store.
Have been working on a new GUI for the AutoCI application.
The app will include a screen to show the Checkins that you have configured…
You would be used to the concept of the Auto Check Ins, which automatically handle the checking in and out as you roam around. We are also looking into introducing Manual Check Ins. Manual Check Ins are basically dormant Auto Check Ins… they are not active until you manually select and check in. After that, it will function like an auto check in and monitor your position and check you out when you leave. It would then become dormant again.
The app will also include a screen to show your friends checkins…
The Friends check in screen allows you to create groups to more conveniently display your friends, and swipe between the views. If you are using the Auto CI Proxy, and your friends are also using the AutoCI app, then it will display their most recent check in or check out…
Anyway – the new GUI is going through a few last tests… and will be released with the next drop in the market… hopefully soon. Note that at this stage it will not be the default GUI, it will only be accessible through the menu or preferences, until we have confirmed that it is stable.
If there are any ICS users out there who would like to test the newer version on ICS, please let me know (Jeff ??).
There is a new version of “Auto Check In” nearly ready for release.
If there is anyone out there who is already using the paid version, and would like to test this new version prior to release, please send me an email at:
The main new features include:
- Moving to an SQLite DB backend – removes all this stuffing around with having to backup the AutoCIs before upgrading. Will also simplify future extensions to AutoCI.
- Improved positioning accuracy – the application does NOT use GPS for determining your location, so I have been working on tweaking the algorithms used for detecting position and position changes. SQLite was key for this.
- Revamped network connectivity, supporting use of an AppSpot hosted AutoCI proxy – no real added value for users as yet, but in the future will allow users to define private venues, as well supporting the sharing of user checkouts.
- Various bug fixes.
So let me know…
Any questions, suggestions, just ask.