In the rush to try out and evaluate cloud computing offerings, especially PaaS, have you considered a major aspect of how you will build your app? Your users.

Have you considered the following questions before you write your app?  What kind of users do I have? What kind of capabilities or restrictions would they have? Where are they located? Which language do they use? Do they have special requirements for seeing the information in a specific way?

Note that the users not only affect the way your application is designed, but also how you can grow or target the user base of your application. This blog is not about user centric design, but more on specific support you may need on the platform you are developing.

Did you just think you will develop and deploy the app and will consider these questions a bit later when you have better traction with your users? Think again from the perspective of a business application user. 

The moment you realize that you have a multi-language,  multi-location user base, the fun starts. Anyone who has dealt with formats for displaying addresses to different parts of the world (German vs US addresses come to mind) or have to accommodate for users residing in different time zones, or with accessibility needs knows what I am talking about and is probably chuckling by now.

Lately, I have been using this analogy a lot. I usually determine the utility of a platform by the ratio of the application vs systems code writing TIME spent in your total application that is written by the application programmer. Ideally, the app programmer writes very little systems code, and spends most of the time writing application code. The graph may look like this. The red little dot is where I want to be. 

User capabilities and definition is yet another area where you may spend a lot of systems code to enable an application if you do not choose your platform right. The user identity determines the access to the application(s) at various levels, from systems to component access to field data in Force.com. There is a great article about security that you can refer to on that specific topic here. 

The user identity also determines where a user is residing, what language (s)he communicates in, address formats, etc. This is metadata that helps in establishing the way the data is presented to the user in a local timezone, with the appropriate language, etc. Building this kind of systematic support is costly, error prone and somewhat tedious. I am well aware of many developers, systems or app, who would be mostly discouraged if most of their time was spent on building user metadata services themselves.

Enterprise Business apps are multi national, multi local, multi time
zone, multi device these days. Force.com has a rich support of defining
and utilizing user information.

Managing user metadata is an administrator function in Force.com.
Developing user services is not a developer function. The developer does
not need to build the localization, timezone, etc. services. They can
be programmatically enabled, via the APIs, or declaratively set for
users. The main point is the platform comes with  a rich set of "properties" that help
drive the customization of the app for a specific user. Knowing that
they are there should make you think next time you evaluate other
platforms when you have a multi language, multi time zone, multi currency, multi device … user base. 

If you were wondering the full set of features that are available to you decleratively, here is a small tip. In your organization as an administrator role, look at the definition of a user more closely.  Open up Administration Functions > Manage Users and select a random user. It should look somewhat like this, with a rich set of properties. 

Wondering about how to use the localization, languages? Press the little link "Help with this Page" on the right hand corner and check out the "Understanding Language, Locale and Currency" documentation and see how without programming you can enable the language the system should be displaying data, the timezones they are presented in, etc. The help has a lot of details that are already built into the platform that you may now know about, such as how a corporation can support multiple currencies, how should a users address is represented for a specific locale. 

There is a lot of info there, my role is to point out that user management is not a service that you should build yourself but should be able to utilize. It is part of the platform. As a matter of fact, it must be part of any serious platform.

Now, compare this with IaaS platforms where you need to roll all this functionality on your own. That is not flexibility, this is just plain waste of time. Compare with other PaaS platforms where you may be able to tap into a user profiles, such as Google App Engine. Do those platforms give you the flexibility to tap into or utilize the rich user management information regarding users timezone, locale, language, mobility, just to name a few? You will not have the full gamut of services that ARE REQUIRED for any BUSINESS app. You will not find the level of the support you will need as an app developer, you will have to consider building the services for supporting a variety of users on your own. 

Is that where you should focus your time? Or should you be focusing on the application logic instead? Something to think about, especially if you are in the process of evaluating cloud platforms.