Form vs. Function

Function

When we get firewood delivered, I usually poke around the pile
to see if there are any interesting bits that might work better in
my woodshop than the woodstove. The piece pictured below seemed to
want to be a bowl. Unfortunately, as you can see it was difficult
to expose the natural features and make it round. In turning it, I
had to decide where to stop, as I was opening up more of the
missing 80° gap with each pass. I stopped just before plowing
through the undercut side, and ruining the piece. That left me with
something between a functional piece and an artistic statement. Of
course I’m sharing this because I see parallels to the discussion
we are having at work.

Our current challenge is to decide which systems or parts of
systems are going to be hand-crafted fat-client desktop
applications (the stuff Microsoft has labeled ‘legacy’), which are
going to end up in SharePoint and which will land on a phone or
tablet. This is heady stuff, but like my bowl, I think our results
will be defined by balancing our goals between form and
function.

Function

Desktop vs. Browser – Despite the legacy stamp,
I can’t imagine anyone choosing to run transaction processing
systems in a browser. I might enjoy the novelty of processing a
transaction in a browser, but I can tell you from my experience
with our expense reporting system, performing multiple transactions
in a browser is painful. On the other hand, viewing certain reports
in a browser as opposed to on paper has definite appeal. Of course
we still need printed reports in some cases, but fewer than we have
had in the past. Fortunately SharePoint and SQL Server Reporting
Services (SSRS) lets us give that choice to the user. In between
those extremes will be the functional elements that we can break
away from the full-blown transaction. For example, allowing an
underwriter to mock-up and request one of a few changes to a policy
would make sense for several reasons:
1.To add at these features to our rating system would be
difficult
2.These types of transactions occur less than 1/10 as often as
complete rating transactions
3.The component transactions appeal to several people and those
people travel

 

Browser vs. Mobile – Notice that I’m not
starting with Desktop vs. Mobile and for clarity, when I say
mobile, I mean native mobile apps, not simply exposing a
browser-based application on a mobile device. Until we get well
beyond the point of the tablet replacing the laptop, I don’t see
tablets or smartphones being the domain of transaction processing.
I’m sorry, as much as people are all hyped up about being able to
run full-blown Windows on a tablet, they aren’t going to replace
laptops or desktops for processing transactions. You might be able
to get everthing running, but who wants to work like that? For the
foreseeable future, there will be a distinct difference between
apps and applications. Apps will be rifle-shot accurate programs
that allow for handling specific tasks from anywhere. Applications
will remain shotgun style programs that cover a lot of ground from
the comfort of a desk. Starting an automobile claim from an
accident site, with a picture and a minimum of on-scene information
is easy. Processing a complex cash receipt covering multiple
transactions in multiple currencies isn’t going to happen while I
am:
•Using a handheld device, or any device that prevents
simultaneously viewing several legible windows/widgets
•In the absence of a horizontal work surface
•Using a tenuous or unsecure Internet connection
•More than 50′ from a printer

As with browser-based solutions, there are tons of opportunities
to break out specific functions to mobile apps. The approval
process is a great example. Approval is a rifle shot function, and
it has to happen when it has to happen – a perfect match for a
mobile device.

As I have mentioned in recent blog entries, we have been
investigating SharePoint’s capability to fill the “in browser”
circle of the Venn diagram I am imagining, and I am very happy with
those capabilities. The key to SharePoint’s awesome potential is
its ability to connect to the back-end data and the myriad ways it
can manipulate and render that data. The person marshaling the
transactions may want to be at a desk, the person approving a
single transaction can use their phone, but the person who has an
interest in the initiation or the results of those transactions
will be very happy in a browser.

This blog was first published on Daniels
Blog
.

Check out our resource centre for more
SharePoint content from other SharePoint specialists!

Gain instant access to our SharePoint content by following us on
twitter or facebook.

Share this on...

Rate this Post:

Share: