Mobile Devices and Site Design

by  Peter Wilkerson , Search & Discovery Practice Area Manager

Companies are capitalizing on the dramatic upswing of the use of iPhones(r), iPads(r), Andriod(r) phones, smart phones and other mobile devices.  IBM has recently updated their portal development tool IBM Web Experience Factory (previously IBM WebSphere Portlet Factory) to include a new set of mobile-optimized automation components to help developers construct mobile applications.

While some companies are depending on the ability of mobile devices to zoom in and out on their website, the companies making the biggest inroads are taking a more proactive approach.

In a nutshell this means that they are keeping the following points in mind:

* Communicating within the context of user mobility

Smart phone users are often not sitting at a desk focusing only on their phone.  They are walking.  They are talking.  They might be talking on the phone while looking for information to answer their customer's questions.  They are likely to have short attention spans as they hail a taxi, board a flight, order lunch, or avoid being run over by somebody else talking on their cell phone.

* Mobile devices can report data as well as consume data

If the user chooses (privacy is important), a smart phone can relay significant contextual data about their location and the time of day.  You've probably already seen examples of how restaurants, theaters, hotels and the like make use of this information.    This information can also be used to identify nearby colleagues and customers.

* Choosing to Mobilize rather than Miniaturize

As I mentioned earlier some sites are depending on zoom in/zoom out functions to view websites.  But really -- who wants to zoom into a page with multiple portlets and have to move around a page to piece together what they need to know?   iPad(r) users don't have it so bad because of the size of their screens.  The rest of us aren't so lucky.   Additionally, choosing to design for mobile doesn't necessarily mean breaking all the pieces of a page into their own separate pages.  You have to get to those pieces and guiding users intelligently to those pieces can be the difference between a successful or unsuccessful site.

* Prioritize content

One way to get users to the right pieces is to prioritize content.  It's not important to have everything. What is important is make the right things accessible.    One of the first things to keep in mind is this question:  Who is the customer of your mobile site?   The more you understand who your customer is, what his needs are, what decisions she is responsible for making, what tasks need to be completed -- the more you can make sure you are getting the right information in front of your customer.

Once you know who your customer is, you can decide how you want to build the paths for that person to follow to get to the info.  Two common patterns are: Navigational and Search patterns

A site using the Navigational Model (in a mobile context) often has a hierarchical structure of topics which a user selects to navigate, much like navigation on a web page except a mobile setting may have only two or three tabs with a limited set of choices underneath. This model tends to work well when you are not supporting many different types of users and when the information is only a couple of clicks away.

However, we live in the age of data sprawl. In an enterprise setting there might be many, many different users to be supported and data is never only a couple of clicks away.

A mobile site using a Search Model will often have a search bar near the top along with a list of top categories.  On some sites if you select a category you start down a path very similar to the Navigational Model.  In other cases, your selection is entered as a search filter and the user sees a list of documents and can refine their search further with various choices.  What you don't often see is a more advanced search page that you find on websites.  There just isn't the screen real estate to support it.

There is a third model that would be useful for enterprise portals.  For now I am calling it "Community Context-Driven Search."  The idea is not new but I have not seen it be applied to mobile devices.  Every employee of a company can be described in terms of one more "communities of users."  The basic concept is that the search behaviors of communities of users are tracked.   Two pieces of information would be tracked: a) Popular documents based on user ratings and b) the repositories in which popular documents are found.  There would also be a mechanism for administrators to assign popular documents and repositories to different user groups based on input from subject matter experts.

This is how I see it working in a mobile context: A user would see a search bar along the top with a list of user communities below.  They could enter a search term and get the "world" or they could select a user community. (If authentication is required for access to a site, users could be assigned a user community.)  The result is that they would see documents relevant for the type of work they do based on the input of other users and subject matter experts.

In other words, they would get to the information needed quicker and more dependably.  If you are on a phone call, looking for information to answer a client's questions that could be the difference between closing a deal or losing it.

Now seems like a good time to repeat my tag line: "Search IS the Portal."

In a time when mobile devices are taking off search is an obvious choice for solving the problem of how to get users to the right data quickly.

What do you see as your biggest needs for designing a mobile site?  Email me at pwilkerson@davalen.com and let me know.   Your feedback, thoughts, and questions will inspire me to write more.

Oh, and by the way, you can also contact me at the same email if you would like to have a more in-depth discussion about some of the challenges for designing a mobile site's flow for your company.

Lotus Traveler - A No Brainer

by Len Barker, Managing Partner - Lotus Practice

1. Ease of Deployment - Just point the new devices to a URL and, bam, done.
2. Price - If you already use Domino messaging it is free.
3. Problem Free Operation - It just works.
4. No Moving Parts - No SQL database is needed, it runs on the host Domino server alone. 

So why would you choose anything else?  There are few very good reasons.  Lotus Traveler supports the major new mobile platforms (iPhone, iPad, Windows Mobile, Android and Nokia) but there are some that it doesn't; Blackberry being the biggy.  Most of my customers have BES servers and Lotus Traveler servers.  Lotus Traveler has a great deal of remote management capability; there are some clients that require even more.

Tips for pain free Lotus Traveler deployment:

• Deploy Lotus Traveler on 64-bit Domino - you can get up to 1,500 users on each box that way.
• User a dedicated Lotus Traveler server - unless you have a very small Domino infrastructure (maybe <50 users)
• Install Lotus Traveler in the DMZ and use directory assistance to get users information from inside the firewall - no need to put your Domino directory in the DMZ.
• User Lotus Mobile Connect for VPN access to Lotus Traveler and iNotes - easy to setup and it just works well with IBM Lotus Domino.

If you have a very large (thousands of users) Lotus Traveler deployment planned, Davalen has developed patterns to ease registration and server assignments.  Give me a call and we'll discuss what can be done in you're environment, quickly and efficiently. 

by  Dave Jacob, Managing Partner, WebSphere Practice

For this month, I would like to repost a LinkedIn article from Adam Ginsberg, IBM who is responsible for both Web Experience Factory (Portlet Factory) and RAD Portal Toolkit. It gives some insight into when to use various IBM tools as well as the advantages of Portlet Factory for supporting a plethora of mobile devices quickly with a minimum (none) of hand coding.

"Our goal is to make the development of exceptional web experiences as easy as possible for the largest group of developers. In the market place there are many different development technologies and approaches preferred, almost religiously, by different developers including Java Developers, .NET/C#, PHP, Ruby, Scala etc. Even grouping Java developers together is really hard with all the different approaches, tooling and frameworks preferred by different developers. For example, Java developers need to choose between tooling and frameworks like Spring, JSF, Struts, DOJO to name a few.

So from my perspective, with intent to be as open as possible, it probably makes sense to group developers looking at delivering exceptional web experiences via a WebSphere Portal platform into 3 key categories:

Type 1: Enterprise Java developers who are coder-naughts by trade and prefer a traditional enterprise Java development approach, and while there may be tooling, you ultimately dealing with lines of Java code. We provide tooling like RAD Portal Toolkit, but as mentioned above there are definitely groups of developers who prefer or have been instructed (via enterprise edict) to use other Java development tools. At the end of the day we keep them whole by the ability to "house" standard based JSR168, JSR286, WSRP based portlets, regardless of the development platform used.

Type 2: Agnostic coders - this group of developers, have strong understanding of development principles, but may not have deep J2EE skills. Note this includes Type #1, J2EE Developers and many other types of developers like .NET developers who can use a MODEL based development tool like Web Experience Factory to develop sophisticated solutions, without a lot of hand coding or need to get into the weeds of specific tooling. Sure, there's an extension point if you do know Java, but it's really not required for development of solutions. Another attraction point is the out of the box builders to connect to many different types of back-ends, like SAP, Domino and Oracle PeopleSoft without needing to know the ins and outs of those platforms.

Type 3: The traditional web developer who's not going to get caught up in building of enterprise applications. They would prefer to use their web development platform of choice, and would perhaps be happy to wrap it up as an iWidget for including in a portal driven exceptional web experience.

From speaking to customers and partners I find that organizations who are Type 1 will tend to stick to the traditional development tooling, and they are privileged to have a strong pool of deep java developers. That said there is a super-set of developers (i.e. including Type 1, 2 &3) who can use a model-based tool like Web Experience Factory to develop and extend out of the box functionality.

So, with the intent to reach a larger audience and skill set of developers we continue to provide strong investment in Web Experience Factory.

At IBM we also tend to use it for internal development projects like our Unified Task Portlet, IBM Connections Portlets, our IBM Industry Toolboxes for WebSphere Portal. Key reasons include:

a)      For ease of development and

b)      To allow a broader audience of developers to be able to modify and extend out of the box solutions, if needed.

We also find that model-based approach of Web Experience Factory with "builders" make it very easy to:

a)      Explain to developers what's happening within a specific bit of code. If you look at a wizard-like interface and don't have to reverse engineer code. This improves the learning curve and maintainability of solutions.

b)      Maximize re-use - using models and builders, with predefined patterns helps maximize re-use of common assets across teams and projects.

Note, we currently invest just as strongly in RAD Portal Toolkit, but we just don't have the luxury of developing all our out of the box capability in both Web Experience Factory and RAD. As above, we've chosen Web Experience Factory.

Additionally, I would strongly recommend that organizations that are looking to leverage Web Experience Factory invest in skilling their developers correctly with training from IBM or via our partners, like you would any other development platform. I would also encourage engaging with IBM services or a partner on the first project, at least from a mentoring perspective, to ensure you build up the necessary skills for successful project."

See the original posts and comments as well as add your own questions and thoughts here.