Storing Data In The Google Cloud With Google App Inventor

Two product management colleagues from the US and a product manager friend from India reached out to me and said that they are very curious about Google App Inventor. One of my colleagues who is from the SAP Mobile Product Management team wanted to know how user preference data can be stored on the cloud and retrieved when a person uses another app.

For example, a person can say that he prefers a green background when he is using one app and another app can pick up that preference and set the background of the second app green. This feature lets multiple apps or multiple people access the same data stored in the cloud. This is a very powerful feature. Data is stored in the Google cloud.

This is very straight forward to do in Google App Inventor. I created an app where the user choose the background color for the app. The app stores the data in the Google cloud. When the user restarts the app, it retrieves the data from the cloud and uses that information to set the background color.

Here is a video demonstrating the concept using two mobile apps.


Here is the complete code for the mobile application, i built to explore this feature.

The Baby Does Not Like Me

I have been creating a series of apps to explore Google App Inventor, to persuade product managers to prototype and to urge product designers to think mobile first.

Today, I wrote a mobile app called "The baby does not like me" to explore and demonstrate the orientation sensor capabilities of a mobile device. I created the app using Google App Inventor, using which you can create mobile apps for an Android device without writing any code.

In the video below I demonstrate the rudimentary app that I wrote to explore the Orientation Sensor functionality of a mobile device. The code I assembled to make this app is provided below the video.

Using The Orientation Sensor To Think Mobile First

I wrote a simple app today, using Google App Inventor, to explore the power of the orientation sensor in a mobile phone. Using the orientation sensor, we can find out the how a use is holding the phone. It is possible to find out if the user if holding it vertically or horizontally. Since we know the orientation, it is possible to display appropriate functionality or appropriate user interface for that particular orientation.

This is remarkable, because this is something we don't think of when building apps for the browser. So when we design mobile apps, let us not just shrink the browser apps for a small screen. Let's think mobile first when designing applications so that we can take advantage of the numerous possibilities offered by a mobile device.

In the video below, I demonstrate the app, talk about why i wrote it, and share the code for the app.

Logic For Orientation Sensing

An App To Find South Indian Eating Places In The San Francisco South Bay Area

First, I believe that mobile applications are going to trigger a long tail of enterprise software applications. We will soon have mobile applications that are meant for a few people for just a few days.

Second, I believe that 'making to think' i.e., prototyping is the most effective way to design and build products. It is also the best way to convey design intent to the development teams and the best way to verify the value a product brings for customers.

I tried out Google App Inventor for a few months and strongly believe that it will help product managers and products designers understand the possibilities and opportunities thrown open by a mobile device. I also believe that it will help them convey their ideas more effectively to product development colleagues.

I am trying to convince my product management colleagues to give Google App Inventor, a simple Android mobile application creation tool, a try. So I created a simple mobile application that lists a few South Indian restaurants and connects to Google maps to give you directions to the restaurant you pick, from your current location.

Clearly, the app makes sense only for a few thousand people in the world. That is fine because the cost and effort required to build apps makes it possible to build for just a few thousand or even a few hundred people.

In the video below, I show the application and also give a brief explanation of how I built it using Google App Inventor. I hope this post will make you curious about the possibilities of prototyping and the future of enterprise mobile applications.

All the logic you need to build the "Let's Go South Indian Today" app.

Mobile Usage Of Your Products May Change Your Product Strategy

I met a friend who works at eBay, the auction site, yesterday. She shared an interesting story with me. eBay, she said, was slowly moving away from being an auction site to a fixed price online store such as Amazon. Then something interesting happened. eBay product designers and engineers created a mobile version of eBay.

People who use the mobile version of eBay started participating in auctions more than fixed price purchases. This behavior may influence eBay's product strategy, she said.

I find this remarkable. But I am not surprised. eBay auctions mobile brought the adrenaline rush of competition and gaming to you no matter where you are. Users were willing spend more time and pay more money for the experience of competing against each other to get what they want and were willing to pay more for the experience.

I firmly believe that mobile delivery will significantly alter the expectations and behavior of your users.

For designers of enterprise software, particularly human capital management software, this is a great opportunity. This is an opportunity to think mobile first, rethink your software as a tool that helps to connect people and move ideas from person to person rather than move documents from desktop to desktop.

I am cautiously optimistic about the possibility of enterprise software that people would actually enjoy using, may be even look forward to using.

A Google App Inventor App That Auto Responds To Text Messages

I created a prototype mobile app that auto responds to text messages using Google App Inventor

This app, when launched, will listen to text messages and respond to the message saying you are busy and will message back later.

All the logic you need for a Text auto responder app for Android

Storing Data In A Mobile Database Using Google App Inventor

I wrote a simple App Inventor application today to understand how App Inventor stores data in a mobile database stored right inside your Android phone. I followed the tutorial available from www.androidandme.com to create the app.

Storing data across sessions is useful for creating compelling mobile prototypes. Product managers and product designers can create prototypes to test the concept, features and even user experience.

The app below is called "Did I Leave The Oven On?". A user can switch On or switch Off the oven and the app will store the status, when the user returns. The entire App Inventor Logic and a video, from www.androidandme.com are posted below.

I hope you find this useful. Happy prototyping.

All the logic you need to understand how data is stored in a database by App Inventor

Google App Inventor - User Experience from clarklab on Vimeo.

Google App Inventor - Logic For An App That Switches Screens

I wrote a simple program in Google App Inventor for Android to switch screens. You might be wondering why such a simple thing is worth mentioning. This is why.

I am exploring Google App Inventor for Android as a mobile prototyping tools for Product Managers, who do want to or cannot program to create a mobile app. To enable product managers create simple mobile applications, it is important to know how to switch from screen to screen, even though App Inventor has only one screen.

For example, if your mobile app has a total of 5 screens, you hide all the screens but the first screen. Then, you can show the screen you want to show and hide all the other screens.

The interesting this is that you will be creating real mobile applications that will function in a real Android device. That is a lot of fun.

Here are the screen shots of the app and all the logic required to make this happen. The Sunrise picture shows up when the app launches. When the user touches the Go To Sunset button, the users is taken to the Sunset screen. When the user touches the Back To Sunrise button, the users is taken back to the Sunrise screen.

Do not be fooled by the simplicity of the code. You can even create sophisticated apps such as a twitter client using Google App Inventor for Android.

At the bottom, I have also added a video from Jason Tyler, showing how to build the app in App Inventor.

A simple app that changes screens when you click a button

All the logic you need to change screens

Design your Software Use cases for OnDemand Products like Romanesco Broccoli

Design your Software use cases for OnDemand products like how nature designed Romanesco broccoli. Start with a few core use cases. Add use cases in such a way that even a few of them will make a whole product. Keep option open to add or remove use cases where appropriate.



If the development team runs into feasibility issues or time constraints they will still have the opportunity to build a product that is useful, consumable and looks like a small version of the whole.

What If Only 3 Out Of Eleven Soccer Players Knew Where To Kick The Ball?

According to a research quoted in Stephen Covey's book The Eighth Habit, Only 1 in 5 employees said that they have a clear line of sight between their tasks and their team's or organization goals. Stephen says that this is a bit like only 3 players in a soccer team knowing where to kick the ball. Would you support, let alone play, for a team like that?

Any yet, we work for organizations that do not provide a clear line of sight between what we need to accomplish and how out actions help our teams and organizations accomplish their goals.

German National Soccer Team. Thankfully, they know where to kick the ball. I am a fan.

While no software can replace leadership and good management, software can enable some change in behavior. From my interviews with employees in several organizations, I learned that a simple page where goals and activities are listed can provide an employee with significant line-of-sight to organizational goals. Do you have such a page to go to in your organization?

The History Of Information by David Siegel

I started reading The Power Of Pull by David Siegel. Interesting, profound and hard book to read.
Here is a video by David Siegel where he describes the history of information.


The History of Information, by David Siegel from dsiegel on Vimeo.

Build 8, Building 18 and The People Centric SAP OnDemand Team

When I started managing SAP Enterprise Learning, I used to work out of building 8 in Walldorf, which is a bit like the Escher stairs painting. When you walk to a meeting, you could easily get lost and spend a good 15 minutes finding the room. Corridors will suddenly go down for no apparent reason, doors will open to unexpected places and confuse you. The building is so because that is where SAP started small in Walldorf more than 35 years ago. The building was expanded slowly as the company became big.

On the other hand, the new buildings in Walldorf are star shaped. All the necessary amenities such as coffee, restrooms, water, stairs, elevators, and smoking rooms are in the middle of the building. This architecture ensures that people run into each other unplanned, several times a day. When my colleagues walk into the center of the building they can even glance up or down and see colleagues working in other floors.

Building 18, where the SAP OnDemand team works, enables chance encounters and exchange of ideas

Last week I worked from both buildings and I could not help but notice the difference in work atmosphere. I almost felt like it reflected the realization that products today are a collection of ideas and not a result of material processing on an assembly line.

The SAP OnDemand team of product managers, developers and co-innovation people work from building 18. The building enables, and I hope nurtures, the people centric design thinking of the SAP OnDemand team.

Like the architects of building 18, the product design and development teams at SAP are putting people and collaboration at the core of business applications. These are interesting and changing times. Stay tuned.

Don't Just Port. Rethink The Mobile Version Of Your Business Applications

I had a chance to look at several mobile business application demos recently. It is great that enterprise software providers have acknowledged the importance of mobile applications. Unfortunately, several of these mobile application development teams treat mobile apps as a porting exercise.

Recreating a browser based business application in a mobile device without fundamentally rethinking the meaning of that application for a user is counterproductive. It is a bit like cramming a three course meal in an airplane tray table. It is not a very good experience.

I suspect this happens because the application design team hands over to the app to a "mobile team" that ports the existing application to multiple devices. The mobile teams usually have no context or domain experience. So they simply transfer the application features as-they-were designed-for-the-browser to the mobile screen.

My recommendation is to think mobile first when you design your products. Incorporate mobile scenarios in your user stories and rethink the meaning of the application for your mobile users.

To illustrate the need for radical thinking, I picked an alarm clock application that illustrates the possibilities of mobile design. Instead of cramming the screen with more features, the app designers have thought long and hard about what is the most important part of the clock.

Clearly, this app was not simply ported to a mobile phone. Go ahead. Think mobile first.

Convey Your Thoughts Via Concrete, Even Silly, Examples

In the book The Return of Depression Economics, Paul Krugman, starts by describing his style of writing. He says that, while his thinking is abstract, he deliberately chooses concrete, even silly sounding, ideas to convey complex concepts such as "What is a recession?" and "How banking started?".

He takes the example of a baby-sitting co-op in Washington to explain why recessions happen. He also explains how banking was started when common people asked goldsmiths, who had better safes, to keep their gold safe.

If a Nobel prize winning economist, can do it, I am pretty sure humble product managers can convey their ideas through concrete, even silly sounding, examples.

If you are interested in listening to Paul Krugman, here is a video where he is talking to economists at MIT.

Constraints, Ironically, Help Produce More Ideas

In the book Made to Stick, the authors ask the readers to go through a mind exercise. They ask readers to write down all the white things they can think of in 15 seconds. Then they ask readers to write down all the white things inside their refrigerator. The authors say that people produce a longer list of white things when they start thinking about things inside a refrigerator.

I tried this at work last year. In my experience of designing several software products using tens of prototypes, I found that I was able to produce more and better ideas when I started thinking mobile first.

Simple Prototypes Lead To Complex Intelligent Conversation, Complex Ones Lead To Simple, Stupid Conversation

For the past several months, I have been showing prototypes of people management software to hundreds of colleagues, customers and research partners. When the prototype I showed was simple, clear and uncluttered, it led to complex, intelligent and meaningful conversations.

When I showed a cluttered prototype with too many ideas packed in a screen, it consistently led to simple, shallow, stupid and meaningless discussions.

This might be another reason you may want to think mobile first.

The Men Who Motivated Me in 2010

I followed the advice of four men very seriously this year.

Mike Tschudy @MChewD, my colleague and design thinking mentor inspired me to "Be Awesome" and not hold back. Thanks Mike.

Eduardo Salamanca, @esdediego,  my colleague asked me to "Vista, suerte y al toro". It roughly translates to focus, be lucky and to go for your target. Thank you my friend.

Enric Gili Fort @enricgili , my fellow product designer and product manager, who inspired me to "Make Things" and keep my work PowerPoint free. Thank you Sir.

Seth Godin, the author, who through this books Linchpin and Purple Cow, inspired me to shun the mediocore and be different. Thanks Seth. I'll pay you back by reading all the books you write.

The Architecture Of Your Product Needs To Enable The Movement Of Ideas, Not The Movement Of Documents

When I work with my colleagues in Walldorf, Germany, I work from Building 18, which is called the star building, because of its shape. The building is relatively new. Its star shaped architecture enables many chance encounters and micro discussions, which is where many meaningful decisions are taken at SAP.

The bathrooms, coffee, water, discussion tables, smoking room and meeting rooms are all in the middle of the star. So those who need to use the bathroom, drink coffee or water, need a table to chat or smoke must walk to the center of the star. When we we do this we invariably run into a few colleagues with whom we need to talk. There are many tables and chairs nearby to facilitate a quick conversation where ideas are exchanged and decisions are taken.

This change in office architecture has happened in recognition of the fact that most products today are an assembly of individual ideas. The more the interactions, the better the ideas get. The goal of most workplaces in the developed world today is not to move material from one workstation to another workstation as quickly as possible. Instead the goal is to move ideas from one person to another as efficiently as possible.

Designers of enterprise software need to recognize this change in the nature of work. Let us design enterprise software that is a virtual version of the star building at SAP and enable chance encounters of people as many times as possible in a day. Let's build collaboration into the core architecture of the products we design. Let us move ideas from person to person rather than documents from server to server.

Made To Stick

Started listening to Made To Stick by Chip Heath and Dan Heath. @EnricGili recommended it.

The book is full of interesting and useful frameworks for presenting information and make it stick in the minds of an audience. The authors say that the main ingredients of an idea that sticks are

1. Simplicity
2. Unexpectedness
3. Concreteness
4. Credibility
5. Emotions
6. Stories

A good book for product managers and marketers.

Collaboration, Like Spices, Is Worthless When It Stands Alone

More than a decade ago, Lotus and SharePoint pioneered content centric collaboration.  IBM describes Lotus Notes software as an "integrated desktop client option for accessing business e-mail, calendars and applications. Microsoft SharePoint is a family of software products developed by Microsoft for collaboration, file sharing and web publishing. Microsoft SharePoint on its own was a little more than a visual FTP site, unless it was integrated with other business applications using considerable custom development.

Since then, we have moved away from a web of pages to a web of people. Collaboration is moving from being document centric to being people centric.

However, even today, several providers are selling collaboration tools by saying that they have all the right Web 2.0 ingredients such as a wiki, a blogging tool, a discussion tool, a micro-blogging tool, tagging of documents, RSS feeds, profile and the ability to friend or follow people. They also add take pains to point out that they have a feature like twitter, feature like Wikipedia, feature like Linked In, feature like Digg, a feature like Facebook and a feature like Stumbled Upon.

If something else becomes popular tomorrow, the race will be on to add that feature as well, so that they can check off the box with analysts and customer RFPs, which the vendors themselves helped to write. Such providers are selling these tools to IT departments saying that these tools will somehow improve collaboration within the company. Even top software analysts are getting carried away by the available ingredients rather then the overall ability of the software to make a person perform better. 

I think makers, analysts and buyers of such standalone collaboration software are missing the point. Collaboration, like spices used to add flavor to food, must be used to enhance the value of day-to-day work, and even make the work interesting. Collaboration tools without context is a bit like households buying a lot of spices, keeping them in the pantry and hoping that somehow those spices will enhance the flavor of the food they are cooking in the kitchen. If, all it take it takes to serve lip smacking food is to get a bunch of spices and dump them together, every Indian restaurant in the US and Europe should be serving very tasty food. You and I know that, it is not so. So why do you think, this approach is going to work for collaboration.

Look for software and solutions that put people and collaboration at the core, not at the periphery of work. If you do not find such tools today, insist on them. It is worth the wait.

Millennials Prefer Native Mobile Apps To Browsers

Research of mobile usage suggests that people under 35 prefer using native mobile phones to get their personal things done. The research found that Mobile apps are already the dominant medium for access to internet radio maps, social networks, navigation and games.

My conclusion based on my research and personal discussions with tens of millennial students and young professionals is that they have a strong preference for using native apps from mobile devices and tablets. They consider browsers as tools used by an older generation.

Based on my conversation with a utilities customers, I found out that native mobile apps are also a big hit with blue collar workers, not just knowledge workers who do cognitive work.

This is another reason why every business applications designer might want to think-mobile-first for product design.

Duchess and Supply Chain Management

Duchess and Ditto are my favorite dogs. They live in Oregon. I love to hang out with them and wonder what they are thinking. Duchess gets very restless if she is down to the last bag of food.

I got the idea to create use cases as cartoon strips while working on these. Creating use cases as cartoon strips worked well for my current project.

Google App Inventor - A Simple Twitter Client

Google App Inventor is a visual tool to develop simple mobile apps without writing any code.

Today I wrote a very rudimentary twitter client for the Android phone using Google App Inventor. My app enables anyone with a twitter account to authenticate themselves and tweet. It was an interesting exercise to register the app with Twitter first, get the necessary Consumer Key and Consumer Secret codes and connect to twitter from the mobile app.

This may not sound like a big deal for my development colleagues. But it is a big deal for me, because I am not a mobile developer and have never written code for a living. I am a product manager with a product design background, who makes prototypes to understand the market and people.

You may be hesitating to start making mobile apps of your own, thinking that you are a product manager or product marketer with an MBA and limited technical skills. I assure you. You can do it even if you have an MBA. I have one and I was able to do it.

I am convinced that Google App Inventor can be a useful tool for product managers and product designers who like making things. To convince you that it is easy to write app inventor applications, I have posted the logic of the twitter client I wrote here.

All the logic you need for a simple twitter client

Rely On Design Principles Rather Than Slave Over Useless Accuracy

When a product team wants to create a product, there are two approaches. The first approach is for a product manager to slave for months to write elaborate and detailed specs and hand over these uselessly accurate specs to the product development team and hope that they will appreciate the intent, understand the requirements, read the details and develop the product. From experience, we know that this approach fails more often than not. Product managers and developers end up quarreling with each other, bargain with each other and grudgingly accept realities and slowly but steadily become skeptical of each other.

The second approach is to establish a common schema for the team and then write compact stories or simple prototypes that convey the core requirements to designers and developers. The development team members who receive a compact set of stories will rely on a commonly understood schema, which is a set of design principles, to elaborate the compact stories into full fledged requirements and then turn them into products. The important thing to note here is that the people who make the product are given the responsibility to come up with ideas to realize the product.

In large organizations, a design thinking team outside of the regular product teams can take the key responsibility of creating and evangelizing this schema with all the product teams.

At my work place, we have a product design team lead by @MChewD. His team of design thinkers and practitioners have constructed a common schema with core design principles. They evangelize the schema via workshops to my design and development colleagues.

This makes my job as a product designer and product manager a delightful one. I get to focus on the core requirements, convey compact yet clear needs to my colleagues and rely on the brilliance of my design and development colleagues to pour their creativity to turn my requirements into tangible products. Along the way they enrich my intent with hundreds of their ideas and surprise me with things that I never imagined. I get to avoid useless accuracy and focus on the things that create incredible value for my customers.

This is possible because we rely on a commonly understood schema rather than useless accuracy.
Try this approach. I am sure  you will find it useful.

Business Apps Need Names And Faces. Not More Buttons and Text Fields

A few months back, I was interviewed by my company's magazine and I spoke to them about my thoughts on the mobile industry and how it is changing the world in profound ways. I am very sure that hardly anyone read  what I had to say. I rarely pick up the inhouse company magazine and read it. However, when the magazine was published, I went and picked up a copy and turned the pages to look for the article and my picture in the article.

If you think this is odd, I have another story for you. About 19 years back I won a product design award from the LG Group of Korea and they invited me over to Seoul for the award ceremony. A local Korean magazine interviewed me and put my picture on page 75 of the magazine. I have no idea what they wrote because I do not know Korean. But I still have a copy of that magazine with me at home.

This is human nature. We like to see our names and pictures on print or online. We also like to see the names and pictures of people around us and find out what they are up to. This human behavior is exploited successfully by local newspapers such as the Daily Record published out of Dunn, North Carolina. I read, in the book Made to Stick, about the strategy of the publisher of Dunn Daily Record. He insists on having enough names and photographs of local people published in the paper everyday to ensure that people buy the paper and read about themselves and people they know. The circulation of The daily Record is 110% in Dunn. In fact, the publisher argues that if he prints the entire town's telephone directory in the paper, everyone in town will buy and read the paper to ensure that their name and number is printed right.

This was an Aha! moment for my enterprise-software-designer-brain.  I understood why everyone I interviewed in the past two years asks me for a facebook-like interface for their, otherwise mundane, applications. If their names and faces are in the page, they will go there, even if the information on the page is as boring as a telephone directory listing.

I suspect that putting names and faces in every possible, and appropriate, context is an effective way to put collaboration at the core of enterprise business applications and encourage participation. What do you think?  Let me know.