A Few Minutes with AppleCare

A survey request I didn’t mind receiving

This was originally published on my other blog, but I think it works here, too. I know from comments I’ve received on previous posts that some of you are not fans of Apple. I’m not so much a fan of Apple, as I am a developer who has to work with Apple as we create iPhone/iPad Apps for our employees.

I’m not trying to convince you to buy an iPhone, an iPad or a Mac. I don’t care what you use to do your job, pay your bills, process your photos or write your blog. If you’re happy, I’m happy. I use my iPhone for nearly everything one can do with a phone these days. I use my iPad in support of business, especially while traveling. I write my blog, process my pictures and do the bulk of my job on Windows laptops. My wife pays the bills.

Regardless of what technology, platform (if my boss is reading this, his eyes just rolled) or operating system you’re using, occasionally, you need help. Sometimes, you have to deal with a large vendor’s myriad-level-deep-voice-mail-to-nowhere. Sometimes, your request is routed “off-shore.” Sometimes, you’re relegated to a web-based process, be it a chat or an email exchange. Quite often, you’re left on your own to google your way out of a deep hole.

When I began my call with Apple’s Developer Support Group, I wasn’t optimistic. Mine wasn’t a technical issue, it was an account governance issue, and our two development accounts with Apple are governed (on their end) by over 2,000 pages of terms. I can’t share the details of my issue (try to hide that smile), but I want to share six things that AppleCare did well. So well that I would recommend that any organization, technical or otherwise, steal these ideas. Seriously, steal them! This is one case where you want to be like Apple.

The questions speak to the things Apple is trying to achieve.

1) Four simple options – There was no guesswork involved in the simple voice mail prescreening message. Choices 1-3 were binary. They wanted to know if I was involved with three very specific things. I wasn’t, so I pressed 4 as instructed.

2) Hold Music Options – This is one thing that could make all tech-support / customer service so much better. I had the option to: hold with pop/rock, hold with classical music, hold with jazz or hold in silence. Please, steal this idea, even if you only add “hold in silence” as an option.

3) Fast & Accurate – I was expecting my ‘4 – other’ key press to lead me to a long wait. Instead, in under 3 minutes, a cheerful human being picked-up. Matt asked me several questions. He repeated back the important information, use phonetic “N as in Nancy” spelling to verify details like my email address, and he summarized my problem and stated his understanding of my objective. Oh my word, this guy actually wanted to make sure that he knew what I wanted as an outcome!

Unfortunately, after all the gathering, spell-checking and objective understanding, Matt couldn’t actually help me. But, he said that he knew the group who should be able to help me. Now you know as well as I do, that this is where customer service sinks into a frustrating, seemingly endless, often circular journey of despair. My experience was different:

4) Information gathered and provided – Matt asked for a callback number, in case his attempts to transfer me failed. He also gave me the direct number of the group that he was transferring me to. He put me on hold (previous options, still in effect) for what initially seemed like a long time. Then Matt came back on the line and introduced me to Ashley.

5) Amazing – Number five is now known as “The Amazing Number 5!” I’m talking five golden rings amazing. When Ashley picked up she said: “Matt briefed me on your issue.” What? What tech support school did you guys go to? I was expecting Ashley to start at the beginning, run me through all the questions and then punt me to some no-nothing-schlep who would repeat the process. I didn’t have to repeat anything. She began with a summary of my problem and my expectations, as she understood them. She was correct.

Ashley couldn’t help me achieve the objective I wanted, because Apple doesn’t permit the type of account management I wanted to establish. She did, however, offer an acceptable alternative. She carefully explained the alternative and I agreed that, while different than what I had hoped for, it would work just as well.

6) Insure success – Before hanging up, she asked me if I knew all the steps I had to complete and if I knew how to complete them. She listened while I explained my next steps, she confirmed that my understanding was correct, and she offered to stay on the line while I completed those tasks.

Except for maybe giving Ashley a sweet southern accent, I can’t imagine anything that could have improved my experience. Again, I’m not shilling for Apple, but I do think there are some lessons to be learned from this experience.

The Cost Benefit of User Experience

What are people saying about the last thing you built for them?

I’m doing you a favor today. I’ve written about this subject before, but I’m going to spare you the trouble of searching my blog and I’m going to spare you the accidental navigation (if you’re reading this on a mobile device and trying to scroll) caused by me inserting a bunch of links to previous posts. I’m looking back over my 35-plus years doing systems development and I’m going to summarize the whole thing for you:

The people who use the systems you build deserve the best experience you can give them.

There. That’s it. That’s really all you have to read. If you are wondering how I came to that conclusion or why I’m bringing it up, feel free to continue reading but if you’re content to nod your head and even grudgingly agree with me, well then, off you go.

OK, you stuck around. You know what that means. You’re going to have to read a story.

In 1988, I was in a meeting with my boss, a representative of our underwriting department and one of my better programmers. We were discussing a feature the underwriters wanted in the system we were developing for them. First, a little background (hey, you had your chance to leave):

Nuclear reactors get shut down for stuff like refueling and when they are shut down we charge them less for insurance. The way we do this is by dividing the year into a series of consecutive time intervals, each with its own set of state variables and its own pro-rata premium. Creating a new time interval was a big deal and a difficult process prior to the system we were writing. The designer wanted to make it easy. He wanted the system to show a list of time intervals and let the user highlight one and press the “+” key to insert a new time interval after the highlighted one.

This seemed like a simple request and I agreed to it. The designer wanted more. Since we had never had such an interactive feature in a screen before (this was running under DOS), he wanted us to build a prototype. I told him that wasn’t necessary. I told him that he could see the working element as soon as it was done. He argued that a prototype was necessary because this was a “radical departure from any previous approach.” He also added that he wasn’t sure we could make this. I slammed my hand on the table and said:

“If the feature you want can be programmed on a DOS PC, she can build it. We don’t have to prove that to you up front, just let her do her (expletive) job!”

After the meeting, the woman came into my office and said:

“I appreciate your confidence in me and I like the way you stood up for me, but I don’t actually know how to do that.”

I knew that, but as far as I was concerned, that fact was irrelevant. She could learn. The feature was going to make someone’s job easier and that was worth learning how to do.

Today, as we are in the early days of a new wave of development, I am more convinced than ever that the effort required to build a better user experience is a price worth paying. The math is simple. You build a system once every three to five to seven years but people use that system every single day. Where do you want them to register on the UI-O-Meter?

As an added benefit for those of you who stuck around, I am giving you the answers to a few common problems. Note: I have tested all of these:

“We don’t have time to do this” – Give them a choice of waiting a little longer or accepting a second phase to the project.

“We can’t do that in SharePoint” – Buy an add-on feature or hire one of those SharePoint whiz-kid consultants who can.

“This can’t be done in SharePoint” – Move the process to a different platform.

“This would take too many development hours” – Do the math. Development hours vs. hours spent using a crappy system.

If all of those fail, slap your hand on the table and sprinkle in a few bad words.

If you have your own favorite excuse and an alternate way of looking at it, please add your thoughts to the comments.

Maybe, Just Maybe

I’ve been on vacation this past week, trying to put great distance between my thoughts and thoughts of SharePoint. I have spent most of the week doing what I love to do – woodworking and construction. Both hobbies give me the opportunity to build things and to use some pretty cool tools. Ironically, the opportunity to use some pretty cool tools brought my thoughts back to SharePoint. The manager of our small group has installed a trial of Nintex Workflow and due to some budget magic we might actually be able to afford this product this year. Our tasks are to determine two things: 1) can we get by without the Enterprise Edition (if you’re new to Microsoft or SharePoint, ‘enterprise’ is the word they use in Seattle when they mean ‘expensive’) and 2) is there enough utility in this product to justify the expense.

We have been drooling over this product for a long time, but our desire rose dramatically after listening to Marcel Meth talk about it at an AIIM New England event last November. We like products like this because we like adding functionality to SharePoint but we don’t like writing a lot of code. I have only started poking around (I am on vacation) but I’ve seen ‘Calculate Date’ and ‘Regular Expression’ categories and I have wanted those for quite some time. I also noticed ‘For Each’ and ‘Loop’ and that makes me think I can stop writing those three-cushion bank shots to force SharePoint to iterate over a list by updating an unrelated ‘index list’. I know that Microsoft has added looping to SharePoint Designer 2013 but we’re still using 2010, and I’m guessing Nintex’s implementation will shine a little brighter than Microsoft’s.

In addition to looking ahead to SharePoint 2013, we are also looking at the possibility that we will one day want to move SharePoint to the cloud. As we invest in tools, we want to be careful to work with vendors who are also looking to the future. Nintex seems to have that same view, so I think we are safe in that regard.

The main reason we look at solutions like this is because we want to be able to move activity into SharePoint. Content management is more than storing documents. Documents often get created through a collaborative process. Once created, documents sometimes cause other processes to start. The notion of content-centric applications is one that we are very keen on seeing come to fruition, and we want that to happen within SharePoint. We have had some success building solutions that let documents get created, be processed through a basic life-cycle and move to become company records, but we want to be able to handle complex processes as well.

I’m not sure if we’re going to pull the trigger on this purchase, the price is high. Being in the insurance industry, we are grounded in the concept of necessary volume or critical mass – a.k.a. there has to be enough premium income to cover the potential risk. Similarly with this product, we have to see enough utility to justify the cost. In making that determination, we will consider:

How much time will this product save? Let’s face it; we could probably do most of this in client-side code so this product has to make accomplishing our goals easier.

How often will we use it? This is really the volume question. Even if owning Nintex will reduce our development effort by 75%, if we only use it twice a year it won’t be worth the investment.

Is Nintex critical to anything? Some products are justifiable simply because, when you need to do “X” it’s the only way to get it done. I doubt we are going to find anywhere where Nintex is the silver bullet, but we should look.

If the evaluation is positive, I’m sure that I will write about our experience with the product.

Have a great Labor Day weekend; I’m going back on vacation now.

Jump Starting Imagination

If you build things in SharePoint often enough, you are going to have to answer the question we were asking ourselves this week – how close to real do you make a prototype? Personally, I have never liked the idea of building a prototype with the thought of turning it into a permanent solution. Build it, learn from it and then build the real thing.

A few days ago, we met with one of our attorneys to discuss a site that we are going to build for official business documents. Some of these would be governance documents like our company Constitution; others would be things like committee meeting minutes, contracts, reinsurance agreements and the like. We were initially tempted to call these “legal” documents, but in reality, they are documents that simply require a lawyer to be involved during creation and revision. That may seem like a bit of irrelevant semantics, but I’ve learned that when lawyers are involved, semantics are never irrelevant. I mention that because it’s also part of the reason I chose to build a make-believe demonstration site, rather than a crude working example.

Instead of Governance, State Filings and Committee Minutes, we created Jupiter, Saturn, Earth, Venus and Mercury. We grouped Earth, Venus and Mercury into a Quick Launch heading called “Inner Planets” to show that we wouldn’t need a mile-high Quick Launch bar that listed every single committee that might ever hold a meeting and create minutes. We gave every planet a site-metadata column called “Current Version” and we gave them all at least one unique column of metadata. For example, we know that State Filings will be organized by state, so we made sure one of libraries had a state choice column. We populated every library with enough sample documents to set all the parts in motion. Once we showed the attorney the libraries, the kinds of metadata we could build, the way we could build web parts and workflows that used that metadata, he came up with several ideas, including:

A sub site to support collaboration on documents like State Filings. This will have libraries where lawyers and other experts will store everything they encounter and use during the draft and review process, as well as lists and calendars to aid the process.

A document library in the Official Business Documents site where they will store the final version, or perhaps the major versions of deliverable documents, as well as all the supporting documents they feel are relevant in a Document Set.

A records library in which a workflow will create a PDF copy of the final deliverable document.

All of the libraries will be accessible from a parent site home page, which will include a few web parts. One of those will be a list of every document which has been declared to be the “current version.” Another web part will show the documents that have been declared to be records.

The attorney came up with the the idea of a temporary place to build the final documents, a workshop, as it were, designed to facilitate the process and from which they would have to choose what to keep. It’s important to note that:

1) The lawyer would never have been able to suggest his solutions if he hadn’t seen working examples of a document set, a library, a workflow creating a PDF and a web part aggregating content of a certain type from disparate libraries.

2) My team would never have suggested a separate collaborative site because we didn’t really understand the process associated with creating or revising these documents.

Could we have done a bunch of up-front analysis, conducted interviews and designed a site that almost met their needs? Of course we could have. Could we have done that in 90 minutes? No way! Not even if you include the 90 minutes we spent building the demonstration site.

In order to get as far as we did, in such a short amount of time, we needed to quickly educate our attorney and jump start his imagination. Once he understood what was possible, he quickly rattled off our requirements. We all agreed that this would have been harder if we had started out working with a draft business document site. We may have not included examples of all the features he ultimately liked. He may have been reluctant to suggest changes to what appeared to be a nearly finished product and we surely would have dropped into discussions about how we misused the terms.

Next week, I am going to highlight the tools we used to build this demonstration site so fast.

Disposable SharePoint

I was pretty sure that I have written about this subject before, but I can’t find it so here goes. One of the things I love about SharePoint is one of the most often overlooked features – the fact that sites can be destroyed. When I say “destroyed” I mean exactly that, deleted, eliminated and removed from use. When I say “overlooked” I mean that we are usually focused on building sites to support an ongoing need or to automate a permanent process; I mean that we are thinking long-term or permanent. In our case, it’s because we tend to focus on Content Management solutions as opposed to playing to SharePoint’s strength of collaboration.

This week, we started the process of setting up a new temporary site, just as I was getting close to eliminating a similar site. Both sites were built in support of a systems development effort, and both benefit from several of SharePoint’s out-of-the-box technology.

The older site was built to organize documents related to a major redesign of our policy rating system. We used SharePoint to hold spreadsheet models, sample reports, SQL Select statements, documentation and we even used a SharePoint wiki to design changes to a user interface. We had a discussion list to track problems and potential solutions and we had a task list to keep people aware of pending deadlines. Today, as we are beginning to build out a more comprehensive site for our underwriting department, we are moving the useful artifacts from the development site to a permanent home. Soon, we will simply delete the old site. I must say that I wish SharePoint had some of the features of my daughter’s old game, Kid Cad, which let you delete structures by running a bulldozer through them or by using explosives. Microsoft could have at least added some sound effects to list, library and site destruction.

The new site will be used to help us as we design and develop a replacement for our foreign reinsurance management system. Right now, we are simply providing access to some reports that are being used to verify our data conversion process. As the system grows and as we start breaking ground on design issues, we will likely expand our use of SharePoint. This makes sense for a few reasons.

Proximity – If you’ve been reading this blog for even a little while, you knew that was coming. Having the things you need clustered together is a good thing. People like being able to find everything about a project in the same general area, and SharePoint allows us to quickly assemble highly functional little areas.

Feels Like Home –Yeah, I’m dreaming, but people are getting used to SharePoint and we are starting to benefit from the fact that they generally know what to do to get from A to B and how to get back to A. That may not sound like much, but navigation was a big complaint early on, so either people have figured it out, or they’ve stopped complaining. We have already delivered some reporting solutions to this department in SharePoint, so I think the feeling of familiarity will actually help us.

Easy to Delete – I have been doing systems development for 35 years, and one thing that hasn’t changed is the amount of stuff that gets generated. Not only do we create a lot of tables, diagrams, reports and data, we tend to spread it around, and forget where we put it. I am reasonably sure that I could find documents related to development projects from the early 1990’s if I looked hard enough. When we do tear this site down, just like the one I mentioned earlier, it will go in one smooth motion.

SharePoint sites can be made to stick around and serve future employees, but they can also be built for a single, temporary purpose. That’s one of the good things about this platform. Unfortunately, humans have a tendency to hold a certain pride of authorship that causes us to keep sites after they have served their purpose. We tell ourselves that “this data might be useful someday…” or “we may need to show this to the auditors…” or “we may want to review this when we make the next change…” Those aren’t hypothetical; I’ve said all three of them before. If the site is good, make it a template, and then light the fuses.

Your Move

For Christmas, my daughter and I gave my wife a piece of wood. Eventually, it will be the surface of the opening between our family room and kitchen, which just happens to be where she uses her laptop. This is no ordinary piece of wood, it is what’s known as Ambrosia Maple and it owes its pattern of stains and small holes from having been infested with Ambrosia beetles. We know that this will be used for the surface, but we don’t know if we will run it up the sides and across the top of the opening, she can make those decisions after the surface is installed. At that point, we will have some scrap that we can hold up, and she can determine whether or not she wants to be surrounded by beetle tunnels and fungus stains or just work on them (and you thought romance was dead).

I wasn’t willing to make that decision for her, in fact, I wasn’t willing to decide what 5’ section of the 8 ½’ board we would use for the shelf – we let her decide. By now, you probably know where this is heading. Sometimes, SharePoint solutions can be designed ahead of time and built to order, but sometimes the process needs to be piecemeal and flexible. If you need to sell this concept, you can use the word “agile” but I like to think of it as a construction process wrapped up in a learning experience. People shouldn’t have to decide what they want before they know what they are buying, and practitioners shouldn’t make those decisions for them. The beauty of SharePoint lies in the fact that it’s malleable and that it can be assembled piece by precast piece and augmented with custom fabricated elements. The power of SharePoint lies in the fact that as soon as the first piece is set in place, it becomes useful.

One of the projects we are working on is at the point where we need some feedback before we can move forward. We have assembled a few libraries of what will be a composite site, but we are reluctant to charge ahead until people put some content in those libraries. We need to know if the design decisions we made were correct, and there are too many variables to say with certainty at this point. The hardest part of this process is accepting the fact that delays aren’t a type of failure. Pausing to reflect on the progress to-date, to refine the path going forward, to correct bad assumptions and to build on unexpected success, are all good things. The fact that we can use what we have built and that building the next section won’t interfere with that use is a wonderful thing!

As I look back over 35 years of systems development work, I realize that the best systems I have been associated with are the ones that evolved. By far the worst systems were the few times the team I was on attempted to leverage a turn-key packaged bit of software. In between those extremes were many well-intentioned, well designed albeit adequate systems. In every case, things had to be the way they were. Deadlines might have forced us into a “settle on a design and live with it” mode, or we might have decided that the function being automated was such a minor segment of our business that it didn’t warrant much investment in design. When I think about the solutions that we are building in SharePoint, systems that will preserve the important information about our company, I feel strongly that we need to take the time to get them right. Not arbitrary delay, not indecisive wandering, but thoughtful progress is the order of the day.

In our case, we are asking the users to populate three of the libraries that we have built. As they do that, they will experience how well the chosen metadata fits the content it is describing. They will get a feel for the degree to which they have to bounce between distinct libraries that we decided hold content that can’t be comingled. They will navigate the links and connections that we put in place and find them useful or wanting. They will have to add elements to several lists that drive the common metadata. These actions will tell them if the site works well. Having completed this first chunk of productive use, they will also see several dashboard elements spring to life, and they should be in a position to decide if they like what they see, or not.

Information Management 101

When AIIM decided to increase their emphasis on people, and spread their net beyond Content Managers to attract Information Professionals, I was thrilled. It may be minor semantics, but ‘information’ is easy to understand and ‘content’ – well content makes me think of ingredients. Ingredients are sometimes managed, like when a factory produces bread, or shampoo or beer, but ingredients are just as likely to be thrown together when you and your 6-year-old bake a pretty good cake. Ingredients sound like the stuff hidden in the fine print. Information sounds important, it sounds vetted and validated and downright useful. I decided to launch a series of training sessions around the concepts of information management because we are involved in a wide variety of systems development projects right now, and many more lie ahead.

The first training session was short, in fact I finished 5 minutes ahead of my 45 minute goal, but that may have been the only thing that the audience enjoyed. The message was simple but not entirely appreciated. That we are all ‘information professionals’ sounds flattering, but pointing out what constitutes ‘professional behavior’ isn’t so appealing. One of the slides that wasn’t accepted well at all was the one titled “What’s Not a System”. From the thousands of things that aren’t systems, I chose four that cause the most problems for me:

Templates – Word, PowerPoint and even SharePoint all make great use of templates, but the idea that building a solution from a template is enough to insure consistency, reliability and usefulness is folly. Templates are like the recipes that guide our use of ingredients. We can change templates, ignore portions, delete portions or put the wrong things in the wrong place. Saying “I used the template” isn’t really the equivalent of saying “I followed the rules” – It’s more like saying “I had the rulebook open at the time.”

Spreadsheets – I like to think about spreadsheets the way I think about sports cars. In the hands of the right people, they are both fantastic. If the people are unskilled, unwilling to follow the rules of the road, on the wrong road or trying to do the wrong thing, the end result will not be pretty. You can move furniture in a sports car, but… Spreadsheets are good at so many things, but pretending to be an automated system isn’t one of them. Spreadsheets are fragile, hard to debug, hard to document, way too easy to copy (and then confuse the copies), and way too easy to be made to look official. Even worse than when people try to use spreadsheets as a data processing system, is when they try to use them as a content management system. The simple row-column interface of a spreadsheet encourages people to store, track and categorize stuff the way the top left kitchen drawer attracts gadgets. When you go back and try to sort and filter your list though, you realize that ‘Cars’ are not ‘Automobiles’ are not ‘Chevys’ are not ‘Vehicles’ and so on and so on.

Folders – My target here wasn’t just the myriad file folders on the remaining share drives in use on our network. I also took aim at the SharePoint libraries that were created, from some of those file folders. Folders and unmanaged libraries are not systems, and they provide minimal (at best) support for managing information. Yes, folders do help us to organize information, but they can’t enforce rules, they can be moved, renamed, and they can hold so many things that don’t belong in them that they are the top left kitchen drawer. Folders are a good starting point, if you have better places to put the things that are in them and if you are willing to throw some things away.

People – Actually, in a failed attempt to be cute, I said “You” are not a system. I went on to explain that people are pretty unreliable when it comes to managing information. People make the rules, but they also forget the rules they make. People take short-cuts through the processes they define, ignore the procedures or convince themselves that rules and procedures were meant to apply to “other” people. The most dangerous thing about people is that they think, and when they think, they convince themselves that changes should be made and then they make them. Systems can change, but only when the changes are confirmed to be appropriate by everyone who will be affected and then only under the control of the same process by which the systems were built. I wish people wanted to manage information the way some want to play football, then I could try something like this.

Teamwork – Meet the Team

I will first introduce myself, as it is not Dan who is writing this blog entry today. My name is Doreen Jacius and I work for Dan. My “real” title is Systems Analyst, but as most of you know from following Dan, I, like Dan participate in many parts of the development efforts within the IT department. Dan has mentioned me (without name) MANY times in earlier blog entries and now it is my turn to attempt a blog entry. I stress the word attempt since it is not something I have ever done before! I have been coaxed into a public speaking situation one time in my life and that is the extent of my experience in this domain. Keeping that in mind, here is my story:

Earlier this week my 11 year old daughter was getting fitted for hearing aids and struggling with how the world sounds to her now. She was very frustrated and the look of agony on her face made me question if we were doing the right thing. When her audiologist told us that it is going to take a lot of time for her brain to get used to processing new sounds that she has not heard in many years, it made me think that is how I felt when I first came back to work and started learning SharePoint. I had never seen SharePoint before and it looked much different than a Lotus Notes environment I had left 10 years earlier. For the first few months of learning SharePoint I was questioning whether coming back to work was really the right choice. I was frustrated that I could not immediately figure out the difference between a list and a library. I then became frustrated with setting up workflows and trying to learn the difference between list, reusable and site workflows. I became frustrated with many things! This is how my daughter is feeling with adjusting to hearing new sounds – she doesn’t ever think her own voice will sound normal again.

Two years later I can look back and say Wow, I sure have learned a lot. Yes, there is a lot of functionality in SharePoint that I am comfortable working with. And holy cow, I know how to create a fairly complex data view web part – when even just 18 months ago, I thought Dan was talking in a foreign language when he attempted to show me what a dvwp was. I cannot count the number of times that Dan would tell me “Just watch and you will eventually get it”. I didn’t always believe him back then, but looking back at the progress our department has made with SharePoint projects; I am starting to believe his words.

This week I am finding that I need to remind myself of this scenario as we move forward into our next, more complex SharePoint project. I am worried about how I am going to deliver a user friendly solution when I am not even sure where we are going to start. The users are becoming more confident that my participation can help ensure a solution with features they are excited about, and that is what is making me anxious. I have heard about “how” we can give them many of the features they would like in SharePoint, but I haven’t discovered the best way to do it yet. SharePoint is a robust product and there is always something new to learn: how to connect to reporting services, how to take advantage of more complicated workflows, how to work seamlessly with a SQL Server database. Although I am now comfortable with many aspects of SharePoint design, I am still faced with the same dilemma. I need to gain more confidence in my abilities to learn something new. SharePoint has been an excellent product to help me and the SharePoint community has helped me when I can’t help myself. I look forward to the new challenges we face and I know SharePoint will play an important role in the solution we roll out. How do I know this? Because looking at the past has shown me that I can learn to do what others have shown me is possible to do.

As my daughter struggles with the adjustment to hearing sounds she has no memory of ever hearing, I am reminded of how I felt when I first started learning SharePoint. In the 24 hours that she has had the hearing aids, I already see a huge difference in her tolerance of them – I know my SharePoint learning curve won’t always be as speedy, but as I venture into new projects I need to remember it wasn’t that long ago that I didn’t know the difference between a list and a library.

Avoid the Excel Trap

Earlier this week, Marc Anderson called attention to an article in the Boston Globe about a company that is requiring all of its employees to learn JavaScript. That spawned some comments on Twitter which led to a blog post by Marc, which led to a comment by me. Before I start singing “there’s a hole in the bucket dear Lisa…” let me jump to the point. Systems development, of any kind, by anybody, for any reason, should always follow a few rules.

In my comment on Marc’s blog, I called attention to my three favorite development rules:

• Design your solution following generally accepted principals of systems development
• Test your solution thoroughly
• Document your solution adequately

Now, I am going to add a fourth rule:

If your solution is even moderately complex, don’t build it in Excel!

Excel has been biting me in the hind parts, all week long. I have written several blog posts about the fact that SharePoint is a much better choice than Excel when building solutions that primarily store and lookup information. My suggestions sometimes fall on deaf ears, but when things go south, the problem-child spreadsheets often end up in my lap. Here are two that landed there this week:

Seek and Ye Shall Find – One powerful feature of Excel is the ability to write formulas that gather data from other parts of your sheet, other tabs, other spreadsheets, and even data sources outside of Excel. The problem is that these formulas work even if the lookup data is out of date. Earlier this week, we suffered a curious error due to the fact that someone left a 2010 version of a lookup list in a spreadsheet that had been updated to 2012. This is precisely why I prefer building these solutions in SharePoint and using External Lists or Data View Web Parts to access back-end data. These are live connections to the data and they don’t require the person using them to push “Refresh All” to make sure the list is populated.

It Should Work – One of the most powerful functions Excel has is vLookup(), the ability to find a value associated with an item by finding the item in one column of a table and retrieving the item of interest in an adjacent column. You specify the place to look, and the offset to use when retrieving. The place to look, is a Range of rows and columns either in the a1..c17 format or a defined Range Name. Unfortunately, when you add rows to the data you are looking things up in, you also have to make sure that the range gets expanded. If you don’t, you have the other error we experienced this week, the item isn’t found. Even more unfortunate is the fact that vLookup() doesn’t return “Item not found” by default, it returns the value associated with the last item it checked, which is the last item in the range. Here again, I find myself longing for a solution where one SharePoint list looking up stuff in another SharePoint list. I just have to point to the right list; I don’t have to define the top, bottom, left and right sides of the list.

I know that spreadsheets were the first “killer app”, and some say that nothing has come along on the PC that can rival them; I disagree. Spreadsheet use is out of control; people trust them to do too much work, and they ignore all the rules while building them. Every really complex spreadsheet that I’ve ever seen, was written while one or more people were “in the zone”. They weren’t really designed; they simply morphed into shape as needed. In addition, those solutions are undocumented or poorly documented, poorly tested and they remain in the same fragile state they were born in. Version control is performed by pressing “Save As” and appending a year, event, or people string to the file name. On top of that, I’d be willing to bet 50% or more of the spreadsheets in use today include at least one formula that has been overwritten with a fixed value.

SharePoint offers us an escape from these traps. Rather than try and force Excel into pseudo-database mode, we have a product that is actually is capable of supporting a solution that requires the power and reliability of a database and the control of a content management platform. On top of that, SharePoint gives us a wide variety of ways to extend solutions through workflows and programming. We can automate, protect, distribute and decentralize functions and features without exposing critical elements to random, unauthorized and undocumented changes. I know that it’s easy to reach for Excel. I know how tempting that row-column blank slate can be, but it’s a trap, pure and simple.

Form vs. 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.

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.