Getting mobile apps to the enterprise

Posted on 18 December 2011 by lopataru

Recently I reviewed two mobile applications which can help us use Documentum or Alfresco repositories, respectively.

Besides the novelty which obviously triggered my curiosity, I’ve seen genuine interest from my customers in mobile applications. Some were more precise on the expressed need, others just sensed the opportunity and are trying to figure out how can they use it for business benefit. Tablets are on the rise for sure and the “new user” is one new way to look at your employees and at your customers.

Now… how can we get mobile in the Enterprise? Is it worth it?

First of all. “mobile” can mean so many things I can’t event try to list all reasons here. I’ll focus on the narrower need to enable new (more efficient) ways to do the company business while being mobile. And leverage the mobility traits when doing that (location awareness, communication, gyroscope etc.).

There is also a price barrier. “Mobile” is new for most of enterprise purchasers/managers. But usually they do know that a mobile app costs less than 5 USD in average (perceived end user cost). Which leads to a puzzling discussion when trying to budget a custom solution which easily jumps higher than tens of K in any corporate environment.

Now, the mobile apps which I reviewed from EMC and Alfresco are both free (at least to some significant degree, fineprint always exists). So why worry?

Because all businesses I saw are not willing to give their employees (and surely not their customers) these applications. While I’m sure there are companies out there which will do exactly that, the majority will want a custom solution for custom business rules and especially for a customized experience (remember… “new user”).

And this is where partners and consulting practices get involved. Especially in “old” ECM technology areas (eg: EMC, IBM, OpenText) where there are a lot of talented people which worked their … off with cumbersome APIs and never ending projects. They would love to try the “new stuff”. So, let’s help them! The innovation will surely come from these people.

Why do I write this? To promote the “open source” way to the traditional commercial vendors. Such partner companies or consulting practices are most likely not inclined to invest a lot in the creation of mobile solution from scratch. They need a quick ramp-up. If they have it, then mobile solutions will bloom on that ecosystem and they will be pushed into the enteprises because those enteprises are already using that “big” software platform and would love to add incemental inexpensive pinpoint mobile solution addons.

Here’s what I suggest EMC/IBM/OpenText should do:
1. Create a reference “generic” mobile application. (EMC is there already)
2. Have a solution certification programme
3. Open up the source code of the reference mobile application to the partner community (at least)
4. Validate the mobile solutions made by partners and give them a certification (one can even go further and allow only certified mobile solutions on the platform).
5. See the mobile footprint grow

Or simply open source the app and let it all go run free – the Alfresco way.

Both methods are ok I think, given the different approaches of closed and open environments.

So, EMC… IBM…. OpenText…. Microsoft… are you going this way?

Alfresco Mobile iPad application – a short review

Posted on 26 November 2011 by lopataru

I’ve been trying to write this post for a veeery long time. Actually, I can use the application itself to tell me how long: “58 days ago” it says near the first offline downloaded document.

First things first. I aimed to review the app in order to compare it to the EMC Documentum iPad app which was also released in the same time neighborhood (also reviewed by me previously). I was very curious to see if an Open Source mindset generates something different and how.

Installation

I downloaded the app and clicked on it. And… it worked! I mean, it was already connected to a public Alfresco repository which I could browse and use immediately. I must say, this was very nice.

Comparing with the EMC Documentum app where I had to walk through a convoluted server install process in order to connect the freshly downloaded App to the Content Server, this was like a sunshine coming after a storm.

Grade? 10 out of 10

Ok, the app worked, I was very happy, but I needed to make it connect to my Alfresco installation, not the internet public one.

Configuration

The app configuration options are not within the app itself but they are within the Settings area of the iPad. This is different from how EMC did it. in the EMC app, the cofiguration is within the app. I’m not sure which I like more. I tend to like the EMC approach more, even though I appreciate the fact that Alfresco uses the Apple guidelines on how an application should expose its settings.

But there is more than meets the eye. The Alfresco App can be configured to connect to 1 and only 1 Alfresco installation. Switching to another installation can be done only by entering the iPad Settings area again and modifying the existing parameters. The EMC Documentum App allows you to have multiple profiles, each mapped to one repository and you can switch between them from within the app itself, without needing to modify any of them.

I think EMC got it better here. A lot better. I would have expected Alfresco to be more in tune with the thought of having multiple alternative connections, since you can more easily find multiple Alfresco instances in an organization than multiple Documentum ones (after all, Alfresco does tend to be used at departmental/division level).

Grade: 8 out of 10

Prerequisites

What do I need to install on the Alfresco server in order to have the App connect to it? Nothing. Nada. Zip. You have Alfresco? If yes, then you have also the CMIS services there and this is all the Alfresco iPad App needs to.

Easy as it gets. Grade: 10 out of 10

What do you need if you want the EMC Documentum iPad App? Don’t get me started! Read my previous post.

Features

I will not do in great detail here. Mainly because I did not explore it all in detail and I must say my knowledge of Documentum exceeds the one I have on Alfresco so I’m trying to keep it as fair as possible here.

The Alfresco iPad App has the usual browsing/searching/offline download/tasks(activities) features you would expect. Similar with the EMC Documentum iPad App.

Where I have seen a diffrence is that:
1. you can actually see the content of documents from within the app (in the Documentum App you can’t have that without installing yet another software)
2. you ca ADD content. So the application is not only a readonly view of the repository. Which is very good.

I’ll give it a 9 out of 10 for features. Because there is always room for more here.

Overall impression

One thing to note here is that the Alfresco App is actually a relatively small modification of the FreshDocs app from ZIA Consulting (which is another CMIS browser app on iOS). Which goes to show that open source companies tend to be more agile in their partnership strategy and more open about it.

Another thing which I very much appreciate with the Alfresco iPad App is that it follows Apple design recommendations for design. It’s very simple and straightfoward to use. This differs a bit from the EMC approach, which followed the style of the Twitter iPad application – more colorful and with the sliding decked panes. Although the EMC has more eye candy, I must say I prefer the Alfresco decision. Plus, is an universal (iPad & iPhone app).

And another thing: The Alfresco iPad App connects to the content server using CMIS. The EMC Documentum iPad App connects using a (yet another) proprietary communication protocol. not DFS, not CMIS. Eating your own dogfood?

Last but not least, since the applications were initially launched (more or less at the same time), the Alfresco App already had a new release with new functionality. And that says a lot.

Did I say “last”? I was wrong. The Alfresco iOS App xCode source code is indeed open source.

Good job, Alfresco.

EMC Documentum iPad App – workflow tasks

Posted on 29 September 2011 by lopataru

This is the third and last part of my review of the EMC Documentum iPad application. I wanted to see how it behaves for Documentum workflow tasks.

Briefly, there are 3 major categories of workflow (aka processes) you can run in Documentum platform (aka xCP sometimes):

- quickflows. One user wants to send a document to a sequence/set of others. Ad-hoc, no predefined rules.

- standard document routing. A process template is defined and an information package can be routed through it.

- xCP process. much closer to a pure BPM flow, very similar actually to the document routing above, but with more features (Eg. more advanced forms, integrations etc.)

The process templates are build using Documentum Process Builder using also Forms Builder… etc. All part of the Documentum “xCP” bundle.

Now… the Documentum mobile (iPad) application says it enables users to work with tasks in their inbox. All the above workflows/processes end up in the user’s Inbox as tasks. Let’s see them!

Quickflows

Test scenario: pick a document, start quicklow, select 2-3 users as destination, enter some instructions, click some options…

Work just as you would expected (after reading my previous posts). You see the task in the iPad app Tasks list, you can click on it, see the task instructions as laid out by the originator, you can comment on it and finish it. You can also see the document content (in the same way as in all the other sections of the application, see previous post). Acces to document metadata is a bit clumsy as usual (you need to try to see the document to get a 2-more-taps method of viewing the builtin attributes).

Document routing

Test scenario: design a process template with 1 manual activity, start a document on this process

They are very similar with the quickflows. The only noticeable difference is the name of the task (which is given by the process design not the document attachment, obviously).

One nice touch is that the iPad app allows the user to also “electronically sign-out” the task if requested by the workflow design (meaning the user is asked to re-enter his/hers password… this is the “sign-out” feature). I wasn’t expected that.

One not so nice thing is that once you open the task you see only one “Finish” button. Clicking on it will complete the task (or bring out a menu o alternative options if any are available as designed). You can’t “cancel” the task display (as in “i don’t want to finalize you right now… later!”) by tapping a button. You need to “slide” the task display page away. A bit counter-intuitive. I’ve already seen 2-3 persons clicking on “Finish” to close it. And this was wrong as the task was “completed”. Ergonomy fail.

xCP process

Test scenario: design an “xCP” process (with a “task form”) and start the process from TaskSpace.

Well, here is simple:

The task shows in inbox, you click to see it and wonder how the task form will be rendered. The answer is a “500 Server Error” with a “NullPointerException” reported. End of the test.

As a conclusion:

The current EMC Documentum iPad application can handle simplistic inbox/task features. Can’t be used if the user needs access to custom package/document metadata or the tasks have forms associated with them (not just plain document routing).

As far as I see it. The iPad application is a reasonable showcase of features for basic DMS but just for demo purposes or very very limited real use cases. I stand by my advice to EMC to make the application “open” for partners to extend and get it closer to the actual real world business requirements.

And another thing: the app design should use the iOS/iPad Apple UI design advices. Currently is a bit non-standard. This is good for entertainment apps, but for this kind of software… you should stick with the beaten path in order to make it easier to the “new user” .

Next? A review of the Alfresco iPad App which just surfaced in the App Store.

EMC iPad Application – mind your DNS entries

Posted on 15 September 2011 by lopataru

Documentum Mobile Server and iPad Application and DNS stuff

How does the EMC Documentum iPad App work? Do we need to take care of anything specific?

Well, suppose you installed the Documentum Mobile Server on your Tomcat application server under http://dctmappserver/mobile URL.

The first thing you need to do is define the profile. See my previous post for details on that.

It can come in handy to test the accesibility of the mobile server from a browser. You can safely do this by accesing this URL:

http://dctmappserver/mobile/repositories/

This produces a nice XML with more navigationable URL-s such as http://dctmappserver/mobile/repositories/REPONAME/folders). Enjoy them.

For more hints visit the web.xml.

After all goes well, the application will start to chat with the server when needed. Communication is based on simple JSON HTTP calls. Authentication is HTTP BASIC (so you can play from your browser..).

The conversation is very clean. Again, thanks for not using DFS. Much appreciated!

Ok, but why are you telling all this? Because I was kind of forced to look into it when my installation of the software did not work properly. Browsing was ok but I could not see any specific document type/format icons and could not download any document content.

And now the fun stuff.

The iPad app runs on… well.. your iPad. Which network is your iPad connected to (3G, public WiFi, VPN)? This matters quite a lot because you iPad will need to solve some DNS names while you frenetically touch it .

“names”? As in plural? Yes!

One name: the application server where the mobile server is installed to. This is easily controllable since you entered it when configuring the plugin. So you can put in IP there and forget about DNS resolution.

Second name: the ACS name. This is the ACS server communicated by the content server when you need to download content of a file. While that specific ACS might be accesible by regular Documentum web end users or enteprise applications… your iPad might have a problema with that. Because of the DNS resolution or the firewall. You can control what will be used here from within Documentum Administrator at the repository Distributed Content ACS configuration… ok…

Third name: the thumbnail server name. This is used at least for providing a nice icon for each object you see when browsing on the iPad. And this “thumbnail URL” is a mistery where it comes from. I’m not sure actually who generates it. The thumbnail server has multiple (uh!) configuration files, each in different places and in different formats (user.dat, storage.dat, pfile.txt, server.xml, …). Not documented, of course. Inspecting these files you can see in storage.dat (in it’s “binary” format) what looks like an URL template for getting thumbnails. And which looks extremely and very similar to the one returned in the JSON talk between the app and the mobile server. Here the server name seems to be the one defines as the computer name (I’m not sure if it’s the FQDN… could be). Nobody asked this during configuration so it’s taken automatically when you configure the thumbnail server for each docbase. And why this is not good? Because your iPad might not know that server by that name. And… no nice icons for you!

One can think you can change the value here (binary edit, mind you) and have the issue solved. Wrong! At least for me. I changed it, restarted everything on earth… nothing happened. So.. mind you.. in order to get thumbnails working properly in Documentum Mobile Application on iPad you need to provide DNS services to your iPad to solve correctly that server name. How do you do that? It’s your task, for me I solved it so it can be done.

Now I’m off to see the custom properties handling and tasks.

As of right now custom properties are not displayed for documents. And not even transferred from the server (even though a lot of other/all system attributes are transferred by default).

Also, I have trouble opening tasks… Some null pointer exception on the server.

PS: Did I tell you that I think java.lang.NullPointerException is always a developer error?

I hope this helps other demonstrate this mobile app for Documentum. Making it easier for the new user. Meanwhile somebody is pulling a lot of hair.

EMC Documentum Mobile – a quick review

Posted on 30 August 2011 by lopataru

Some months after being demo-ed at Momentum, the EMC Documentum Mobile client for iPad is finally here for us to actually work with it.

Go to the app store and get the app and go to Powerlink and get the server component. Can’t find the Documentum Mobile Server component in your download basket? Ask you EMC representative and sort it out. It’s kind of limited access right now.

Been there, done that… kit on my hands… let’s go! Here are my first impressions, not very filtered but a bit digested:

The Version is 1.0. We should note the choice of not making it 6.7 as in the current Content Server version although it’s supposed to be a part of it in the future.

First thing is that you need to install a server component to make the App talk to somebody. Of course, nobody expected the app to talk directly to Content Server but… maybe some expectations were directed towards the DFS way.

Well.. it’s not gonna happen. DFS unfortunately has proven quite a hog for some apps and this time EMC chosed to go the JSON way with “RESTful services”. I’ll give them 10 points for that, it’s an excellent decision. Sorry DFS, not a big fan here.

That being said, we notice that currently only Tomcat and JBOSS servers are supported. On Windows and RedHat. Strange. Not a problem here but I can’t imagine why aren’t many others J2EE/servlet containers supported.

Standard requirements in hardware, nothing to see here.

Content Server needs to be very new (6.6 P10 or later). Also, a number of other products are “optional” but very useful: CTS and the Thumbnail Server. And some BPM DAR and Collaboration DAR. Makes sense for us who know what’s inside, but suddenly making the Documentum “mobile friendly” became a bit too complicated. Shouldn’t be so.

I’ll give 7 out of 10 for prerequisites.

During install you jump through the many hoops of unpacking the WAR, update the dfc.properties, repack the WAR… Somebody should find a better way for this.

Therefore, a 7 goes to the installation procedure. I was leaning to an 8… but not really because…

When you fire up the iPad App you need to create a “profile”. The profile directs the app to a certain mobile server and docbase. It asks for an URL of the mobile server. Help is of no use, says the admin will tell you what to write there. Since I am the admin I should know. But it’s not written anywhere (install guide/release notes/help docs)! So I take a leap of faith and type an URL mimicking the installation test: “http://server:port/mobile/”. Loading………. 404!

Ain’t that cute? As usual, the answer is simple: remove the trailing / from the URL and try again. So, note to all of you out there: when asked for the “Server URL” put in the complete URL to where you deployed the WAR but don’t put any / at the end.

Contextual help should provide a sample. Or the profile definition form itself. EMC… please.

When all this is done the application just works. Really.

The UI is inspired from the Twitter iPad app. Very responsive and easy to work with. Relatively intuitive. It definitely looks ok.

Since my environment does not have yet the Thumbnail server and I was only connecting to an empty new one… nothing fancy to see.

What I’ve noticed is that the properties displayed for each document are very limited: name, modified date&by, size, subject and owner. I’ll check for a custom object later.

Some errors ocassionally. Even a crash. But it’s somehow espected from a first version.

Since I don’t have the collaboration DAR also installed, some features don’t work (but I can comment on documents !). It would have been nice to have them disabled in the UI instead of getting an error when trying to use them… but still… the error is “intelligible” (“the repository is not configured for…”). Ok’ish.

As a general note for the app, I’ll give an 8.

So, as a quick conclusion: it works, not a pain to install but with a lot of dependencies, good mix of features (browse, tasks, comments, download offline, watch, spaces, collections…), nice UI, fast (on an empty repo ). Sound very good for now.

In the next few days I’ll look into how it handles volumes and custom stuff. I’ll not look into the collaboration features.

Documentum and FileNet – users and groups

Posted on 19 July 2011 by lopataru

This is a story about how design decisions can make your life really hard on the long run.

As a short technical info…

Documentum has groups, roles (actually groups with “tagged” as roles) and users.
Groups can be defined inside Documentum itself or taken from an LDAP source. Mixed.
Roles are not much different, you can use roles and groups interchangeably for the most time.
Users can be defined inside Documentum, taken from LDAP or mapped to OS users.

FileNet knows about groups, roles and users.
Groups and users are always from the LDAP (ActiveDirectory). Only. Replicated from.
Roles are strictly tied to the features exposed in the standard UI (Workplace).

Both Documentum and FileNet have permission sets with some templating features.

And now ask yourself how many times did you need to “group” together users in your CM solution. Aiming to enable one user access to some data just by adding him to the proper group.
Quite frequently, didn’t you?

In FileNet this means the group must exist in LDAP and users must be in that group in LDAP. Not in the DMS system. Oops! Here comes PITA! You need to call IT to create the group (usually manually) and add users in it. You can’t do it directly through a DMS API or admin interface.

As I understand it, somewhere in the design time for FileNet, somebody took the decision “we’ll take all our users and groups from the LDAP”. After all.. LDAP is where users and groups should be, isn’t it? By this decision they actually limited the flexibility of the platform for solutions and imposed a great deal of stress on the real world solution builders.

In the real world you don’t have all your business groups in LDAP. At least not in the majority of organizations. Also, the LDAP structure is generally managed by IT not by the business. Sure, we have “identity solutions” on the market but this is still a long way from having it implemented and properly used.

Sorry FileNet, but this round goes to Documentum.

On folders, search and CMS systems

Posted on 7 July 2011 by lopataru

I was surprised by the level of debate generated by “folders”, “search” and what they mean for a Content Management System. As far as I’ve noticed, there was an AIIM blog post kicking the folders, then Pie defended them. Then… some Twitter chatter sparkled (see @pmonks and @piewords), a rebuttal post and a new explanatory argumentation post. And I’m sure I missed some.

I haven’t seen something similar since the “Is WordPress a CMS” topic.

Where am I standing after about 10 years of CMS systems, some 100+ enterprise projects and a significant level of gray/pulled hair?

In a decent to huge (E)CM platform/solution….

1. Folders must not be something you need to think of when building the solution.

The CMS platform should not mandate you to “tell me in what folder do you want to put this document”. It should be an option you take because it means something to you not because the technical architecture asks you to.

I’m speaking of “folders” from the user perspective, not from the OS/underlying architecture of the CMS. The latter must be a completely disconnected feature (but should exist in its own, also).

2. Search is fundamentally important

But it has so many facets (pun intended). I remember a session with a high ranking technical officer from EMC which said “we have never realized until now how important search is”. This was about 4 years ago, but many years after the “maturity” of the EMC Documentum platform. And Search was just beginning to be understood.

Search is one of the very few ways you actually get to use the content you manage. And usually the most important one.

In my world search means:

- to be able to navigate through a clear taxonomy and
- to be able to do a simple search (so called “Google search”) and
- to be able to do an advanced search (the dreadful UI in which you pick criterias and construct your query) and
- to be able to explore the repository (aka faceted search, metadata driven navigation…). Guided but not forced onto a path and…

Folders can be either shown as a representation of the clear taxonomy or the manifestation of the facets (think “breadcrumb”). In some crazy systems folders were saved searches (ApplicationXtender anyone?).

See? Folders and search can really get along…

In my recent solution designs I almost always use all of the 4 methods above to empower the user. When one is not used is simply because the business needs and technical needs don’t require it.

3. Metadata needs to be used at maximmum

You can’t have enough of it (mainly because users will not enter it and automatically extracting it’s still in infancy). Thinking the most adequate classification schema for your content is close to art. Must be enough to do the search and other logic (eg: retention, processing) but not too much so it becomes a burden on users so they will avoid it.

4. You need to build trust

One particular reason users are navigating and not searching (traditional search) is because they have learned not to trust completely the search results. Did the system return all I asked for? Do I ask correctly? Was the metadata entered precisely as I need it?

Somehow users trust more a folder structure. Or a faceted navigation. They feel the results are more precise. The mind is at peace. That’s why sometimes you need to mask the “search” in a different form (eg: “see related…”, “auto-complete”, “suggestions”).

Notice that I never talked about “search” as in “search technology”. As a user I don’t care if beneath the UI its a SQL mammoth or a FAST/Lucene/younameit search engine. For the sake of this discussion you shouldn’t care also.

Can we go now? Thanks.

How to build software for enterprise

Posted on 20 June 2011 by lopataru

Flower Power in the Enterprise?

Yesterday I was reading this fine presentation by John Newton of Alfresco: “Who killed ECM?”.

Before digging in the rest of the post, let me just say I admire what he did with Documentum and Alfresco since both are quite a nice piece of achievments and I believe his input was significant. This is not a post contradicting that presentation ideas. But it stirred something.

Now… I on the topic on how to build software for the enterprise…

One of the most important things I learned is that building something revolutionary is one thing and building something repetitively, deterministic and within time & budget is another thing.

Software creation involves a big dose of… creativity, duh!. And flexibility. When it meets “the enteprise” it needs to be a little different. The employee of the enterprise uses the software but does not influence it too much. Control and precise results are key.

While I also think the employees need to be listened to when building the software which they will use, I also believe that more importantly is that the software project needs to fit within a (rough, at least) budget, timeline and be predictible in the results.

For this to work you need to make people work in a predictive manner. Software devs must work towards a short term goal, emplyees need to work towards a short term goal.

I know… software guys will say “I sometimes do in 1 hr what in other times I do in days. Gimme a break with all this control obsessed freak you call manager!”. Well.. you need to be a manager who understands this and keep the adequate rithm while removing the obstacles ahead of the team. Understand how software is done and don’t expect results measured by pure man-hours.

To call in a methaphor, when creating a new and revolutionary type of software it’s like nourishing a new flower breed. When you build for the enterprise, you need to deliver 200 packs in 2 months. And they all must be fresh and smell good.

galere

Usually you don’t achieve the 200 packs by letting loose the gardeners in the back yard. You plan, monitor, adjust, address risks, look out for your money and use the Blackberry. The art is to know when to also talk on the iPhone and don’t become a pressure maniac.

Of course enterprise users want the same level of personalization, speed and overall quality inside the company as they get on the outside services (the gap is huge). In order to address this we don’t need to drop de “rigureous” model but instead employ creativity into it. The guys at College Humor have a nice video of the counter model.

So, making successfull enterprise software needs some creative work to kickoff the magic idea and then rigor for execution. Suppliers which do it in either of the extremes might get lucky in some occasions but not on the long term.

The use for an EMC mobile app for Documentum

Posted on 24 May 2011 by lopataru

ios applications

UPDATE Aug 2011:

EMC is launching the new Documentum Mobile. Looks well designed (navigation similar with the standard Twitter client app for iPad). Interesting enough, it does not seem to use DFS (a sepparate REST layer is delivered). More to come after I get my hands on it…

ORIGINAL:

This blog post started as a comment on this post by @piewords. When it got too long it become this:

EMC making a mobile app? Good for ticking boxes in RfPs. Essential sometimes – we actually used in an older RfP response one of the already existing mobile apps from the app store… so the need is definitely here.

Useful for business users? Probably not. As Max said in a related comment, an application needs to actively support a business process not just offer repository services.

But.. there’s more to it!

EMC must make a mobile app and provide the code in EDN (like they said they’ll do). Why? To encourage and empower partners to build their own process/solution specific apps! And this is where I think EMC got it right.

When I look at EMC I want to see an enabler of partners. You do that by bridging gaps and offering examples. Either by building a technology showcase (like the app will be or like the Apple iOS SDK for Atmos is) or giving an xCellerator for a certain business solution.

I recently demo’ed a mobile app for a taskspace based solution. The value was immediately perceived by the user (CEO, CIO…) because it meant specific business and wasn’t generic.

More importantly, the user understands that it’s not a full grown traditional desktop/web “application” and that it does not need to have all those bells and whistles and integrations. Users aim to use mobile apps “transactionally”, for short time bursts. But this is a topic for another post….

How did EMC help / would have helped me in this case? They should / did pave the road to make it easier for me to propose such app to the IT and then to the business. And paved to road to provide a reference implementation (good or bad… doesn’t actually matter).

So… yes. EMC must make a mobile app. Not to make money from licenses or help a lot of users. But to help partners and the whole ecosystem around the platform.

A custom Documentum TaskSpace UI for iPad

Posted on 3 May 2011 by lopataru

UPDATE: See also the review of the Documentum Mobile App here.

I have been playing for a while with the idea of tablet (read iPad) enterprise application development. We have some custom solutions on top of EMC Documentum and others which could benefit from such applications. One of them is being built as we speak, but I’m not going to talk about it here. I’ll talk about a second one.

In the past we have built some mobile friendly UIs but I was eager to refresh that experience.

So, when the opportunity rose, we took it.

Who and why asked for it? The obvious use case: top management which needs a streamlined user interface to some important business actions it needs to take while being mobile.

The full blown solution being made on top of xCP (aka TaskSpace/BPM on EMC Documentum) so we had some possible ways of addressing this: wait until EMC provides an iPad version of TaskSpace or build it ourselves. Waiting is not exactly the strong point of management and also not our way of working. So.. let’s build it.

At this moment I have to thank the EMC Community for making available the Travel App with Mobile UI xCellerator. This provided 2 things: a reference point for us in building what we needed and also raised the customer confidence in our proposed approach.

How it went? Since we still have some work to do in order to polish it (yes, we strive to perfection ) here are some notes:

- accessing Documentum to get the needed information is straighforward (then again, we do have over 7 years of experience with it)

- deciding what to do is complicated. This is where the xCellerator helped – it’s a very good point to start

- building the UI is the thing which takes the most part of your effort (think about 80%). because you need to create a truly good mobile experience, not just a web app

- if your BPM and xForms contain a lot of custom/complex logic then you need to work on it to make it ok on the mobile also (since the mobile UI is actually a completely sepparated web app)

- we used DQL for most processing since going to the DFC/DFS APIs were a bit too slow for what we needed

- we have built our own REST services to be called by the Sencha based UI

Also, please consider that there are multiple ways to build an application for iPad:

You can build a native one (eg. iOS),
You can build a web app which is optimized for mobile devices or
You can build a web app which uses javscript magic to respond to “touch” gestures (eg. use Sencha Touch)

The advantages and disadvantages are obvious but I want to point one in particular: any framework has limitations. Especially new ones. Which will make you work more than expected sometimes to reach a particular design goal.

Also, since your enterprise app probably has a lot of business logic inside which can’t always be described with the ootb BPM toolset, you will have custom code. When building the mobile app you will need to reuse that code. When you started building the solution you probably did not think about the fancy mobile UI you’ll make later. And deadlines did not help either. So, you’ll need to refactor some code and isolate the implementation better so you can reuse it in both apps (BPM/TaskSpace/xForms and your great app).

And please call in a web designer. Enterprise software looks usually lame, building a mobile UI experience gives you the opportunity to make it sexy.

Me and Content Management

ecm4.me – Talking about what makes ECM tick and how it should evolve

Author Archives: