Tuesday, July 24, 2012

Building a Mobile Strategy - Part 1a

As promised, the results of my conversation with the Mobility Guru.

What Is Mobile?
After some discussion, the Mobility Guru and I decided to treat mobile based on operating system (iOS, Android, Win8RT) vs. hardware or form factor.  His original definition "can hold it in one hand" doesn't really account for netbooks or other forms that smoothly run pre-mobile operating systems (Like Windows 7, Linux and the Mac OSs).

The complication with Mobile is not necessarily with the form factor.  It's with the OSs, it's range of implementations (especially with Android), and the difficulty handling various websites and existing applications.

We plan to change this definition.  Especially once we see how Win 8 and iOS Mountain Lion work and evolve.  We both hope that the success of these products will successfully merge PC and mobile spaces so we only have to develop one thing for all form factors. 

I would love to not have to treat mobile as an entirely separate beast.  Instead - mobile-first and it seamlessly goes to other form factors without having to accommodate all of the variation. 

We both may be dreaming.

Mobile Goal/Success Definition - IT
Stated goal (cribbed from the Strategic Plan for IT) - "Lead the Mobility Expectations for the Organization". 

Apparently, this is defined as the following:
  • Improve mobile access (which I guess means get rid of dead spots in our physical space)
  • Engage in outreach (no idea what this means)
  • Content-focused  (which is probably "get our existing stuff mobile-friendly")
Real goal - Not have the Super Muck get yelled at by VP and board member types. I can respect that.

I think they missed a real opportunity to think about mobile in a way that makes our business operations more efficient.  But that's a conversation reserved for my managers and something I sadly picked up on as the Mobility Guru and I picked through the Strategic Plan. After the senior executives asked for feedback. My bad.

Mobile Goal/Success Definition - Training
Training and support - As Needed, Where Needed

IT General Mobile Strategy
Still in Development.  Or as the Mobility Guru put it - it will be determined by whoever screams the loudest.  Guess that's us :)

Device Support
We are assuming BYOD, whether it is stated or not.  Because that is the reality.
We have decided that getting stuff to work on Blackberries will be lowest priority moving forward.
Unless some miracle occurs that saves RIM.

We seriously hope that HTML5, as it matures, will help reduce concerns with content across the various OSs and hardware.

Who else needs to be involved in this discussion?
Mobility Guru and I identified a couple of areas we need to reach out to.

The Web Folks.  Since a lot of stuff will be delivered through their shop, we need to make sure we are aligned with what they already have planned.  Plus they have toys.  We like toys.

Help Desk Reps.  I'm at a University.  Ideally, we'd have one rep for students and one for staff/faculty. 

An IT Architect.  We have one already part of the team, but he's going to be spending the next 6 months figuring out where our entire system is and creating some configuration management.  And that's just the hardware.  If applications were added to that job, he could spend his entire career figuring out what we've got.  We'll keep him in the loop.

So how does this all impact Training?
I took a lot out of this discussion and have a better idea of where I want to head - reserving the right to change course at any time.  I'm gonna call that "agility" :)

Thought #1
We are going to look at 2 tiers of offerings for mobile:
  • Cellular-friendly - text, minimal to no images, no video.  The goal is to minimize the cost to the university and/or employee
  • WiFi supported - this will be all of the multimedia goodies.
Mobility Guru suggested that when we start developing mobile-friendly materials, that we specify whether it is cell-friendly or if it needs to be accessed via WiFi.  Basically - a replacement for my standard "how to work the tutorial" introduction.  Awesome idea.

Thought #2
Leverage vendor content.

With as rapidly as our applications are updating and changing (please see Google),  leveraging vendor content becomes even MORE critical.  Simply because we, as an organization, won't be able to keep up with all of the updates.

We already started focusing on organization-specific tutorials.  I think we need to get better at this.

Thought #3
Design and prioritize performance support

I've already been doing this - especially over the past couple of years. 
My clients, however, have been thinking "courses". 

An argument I heard from a manager was "They can do training while traveling on the shuttle.  It's still work time."  True.  I personally find that time to be valuable thinking and decompression time.  I get LOTS of ideas while not actively engaged in "gotta do" stuff.  It makes me more productive.  But I get where he is coming from.

Thought #4
Web apps first

There is just too much variance in our environment to be able to maintain native apps.

Fortunately - Mobility Guru and his friends are implementing a mobile device management system this fall.  He tells me there are cool things in there I might be able to leverage. 

I'll get a chance to see that up close, since it looks like I'll be creating support materials on it...

Mobility Guru and I decided that chatting about this monthly will be useful. 

This will hopefully allow us to fine-tune our plans and maintain some level of focused flexibility as this whole plan evolves.

Thursday, July 12, 2012

Building a Mobile Strategy - Part 1

My first step: Align anything mobile I am doing with IT.
I have it easy - I am IN the IT department.  However, it is still very important that anything I do maps closely with what the rest of the department is doing (or wants to do).

The more closely I map to IT - the better the support.

In my mind - IT is the group who should be driving mobile device decisions.
NOT the training department.
Why?  Because they are the folks who will be fixing them.

Except for the most gadget-friendly among us, IT folks will also know more about what is out there, what is good and bad, and what they see coming.  Because they will have to support those devices and apps whether they want to or not.

The IT folks I know have a pretty healthy regard for self-preservation and don't like surprises. They also like looking competent - and most will research an issue above and beyond anything you can conceive of so they can a) fix the problem and b) not be surprised again.  Respect these traits.

Make independent mobile decisions and you will have some very unhappy IT support folks.
Unhappy IT support folks will probably not help the success of your program.

(OK - I am getting off my soapbox)
Below I am sharing my questionnaire for my conversation with the Mobility Guru next week.

I will fill in the answers (as much as I can) after our conversation.

I have already given him fair warning :)
What is mobile? (IT Dept definition):

Mobile Goal / Success Definition


Who are the stakeholders?

What other projects involved / impacted?

Device support
Preferred devices?:

Current, most popular devices?

BYOD?  Expectation that BYOD will happen anyway?

Does a general mobile strategy exist yet for the IT department?

Who else needs to be involved in this discussion?

How often do we need to review this?

How can we make it easy for folks to get EVERYTHING they need when working at the University, no matter where they are at?

Solution 1:
What involved / info:
Resources needed: 

Solution 2:
What involved / info:
Resources needed: 
(rinse and repeat)

Wednesday, July 11, 2012

Captivate 6 vs. Articulate Storyline

I am a Captivate shop.
Have been since Macromedia existed (Captivate 2?)
I've used Captivate through UI changes, a couple squirelly updates and the long wait for right-click functionality.

So I go at this tool evaluation more than a little biased.  Because dangit - change is hard and scary.
Especially changing long-standing habits.

But I have more folks I need to support now.  They deserve tools that work for THEM, not just for me.

I was heartened to see Adobe address the HTML5 concerns I had. Still, something in my gut is making me just a little uncomfortable with the way Adobe is headed with this product.  And I have never had end-users seem so excited about a development tool.  So I had to go take a look at the shiny new thing called Articulate Storyline.

I am thinking that NOW is the time to make a change if I need to make a change.  It's the beginning of the fiscal year. I have not purchased the Captivate 6 upgrade yet (though I will need to since I have some folks in the pipeline), and if I have to retire Captivate as a solution - I can do so cleanly with this final version.

I've been spending this past week putting both products through their paces. I created the same quick tutorial (how to use Google Help) with both products.  Exact same steps.  I won't be sharing the tutorial links here since I haven't asked my bosses for permission.
Below is pretty much a copy of the document I shared with my management team.  It is still a work in progress, but at least it gives you an idea of how I am testing.  Noticed how I focused on what I need to do NOW vs. shiny "new" features.

Reasons for looking at changing development tools:
  • Increasing use of mobile for training.
  • Discomfort with Adobe’s mobile strategy for Captivate
  • Feedback that Captivate is tricky to learn and not terribly intuitive.
    • May be overkill for most eLearning client’s needs
  • Unusually positive feedback from Articulate Storyline users during conferences.
    • Many of these users were Captivate users
    • Other tools do not adequately address software simulation

Decision: (not made yet)

Articulate Storyline
Academic and group discounts available.  
Licensing will need to be negotiated

Captivate 6

Useability and Technical Comments
Note: Audio tested in a room with a really large air conditioning vent blowing very cold air.  This did an excellent job of testing any possible noise-cancelling feature in the product.

Articulate Storyline
  • PowerPoint-like interface makes it easier to teach and less intimidating for new users
  • Pre-developed interactions very easy to edit
  • Default to end of slide vs. having to reset the timing for every object like in Captivate
  • Love the scene organization - makes it easier to find and edit sections of the tutorial
  • Movies - really easy to create.  Best screen-capture.
  • Very easy to add objects
  • Audio-recording - weakest part of the product.    Would be better off using Audacity, then adding audio to the project.
  • Have to post any HTML output to test.
  • Keeps ALL items separate - resulting item not as large.

Captivate 6
  • REALLY slow.  Especially initial loading.  Took a couple of minutes to get the product started.  Captivate 5.5 takes about 30 seconds.
  • Themes override ANY settings in your presentation.  This is a “use with caution” feature.
  • The captions not picking up the names of the links.  Just gives a generic.  Captivate 5.5 did a MUCH better job of naming the links.  This will slow down production.
  • Screen capture very slightly better on Captivate 6 than on Captivate 5.5.  Not as good as Articulate.
  • Styles = much quicker caption change vs. Articulate.
  • Firefox plugin crashes when posted and tested on PC
  • Audio slightly better than Articulate Storyline.

Mobile Test (got rid of the table - HT to @oxala75 for pointing out the display problem)

Note: HTML5 output only displays correctly on HTML5-compatible browsers.  Technology not quite ready for prime-time.  (I posted HTML and HTML5 publications on an FTP site our team uses for evaluation and testing of online tutorials.)

Note: Tutorials generated not particularly appropriate for phone-size devices.  Android test (using Samsung Virgin Mobile SPH-M910

Kindle Fire HTML5
Articulate Storyline  Works.  Get “Loading Video” in between each screen.  Can click on Marker to see what happens next.  Is a rollover on PC.  Seem to be missing text captions.

Captivate 6Get Browser not support content warning. Once get there, works clean.  All text captions and audio

Kindle Fire HTML
Articulate Storyline  Works cleanly - better than the HTML5 version.  Resizes correctly and get all markers and text captions.

Captivate 6Works clean

iPad HTML5
Articulate Storyline  Works.  Get Play button before start.  Can click on Marker to see what happens next.  Is a rollover on PC.  Seem to be missing text captions.

Captivate 6Works clean

Articulate Storyline  Does not work without Articulate Mobile Player app

Captivate 6Will not find the page at all

Android HTML5
Articulate Storyline  Takes forever to load. The menu takes up most of the screen real-estate.  Baseline tutorial never loaded.

Captivate 6Get “no support” message. Baseline tutorial never loaded.

Android HTML5
Articulate Storyline  - Will not find the page at all

Captivate 6Kicks to “get flash player” app but my device won’t work with it - then nothing.  Phone used not compatible with the Flash Player app needed.

SkillPort Publication
Articulate Storyline
  • SCORM 2004 publish to SkillPort SCORM 2004 - received error.  Null reading on a file
  • SCORM 1.2 publish to SkillPort SCORM 1.2 publish - clean.  Works as expected.  VERY fast load time to SkillPort.

Captivate 6
  • Works the same way as Captivate 5.5.

I have asked Sid and a couple other end users to look at the Articulate Storyline trial.  I figure they would give me better input regarding usability.  I will use their feedback to help me with my final decision.

Of course - this whole thing brings up the other question of - do I want to have "one tool to rule them all"? Or should I come up with another way of doing this.

Thursday, July 05, 2012

Staring at Tools

I am in the process of revamping my creating minions eLearning program for the University.

I've talked about this before.

I have come up with a few areas this strategy needs to address:

- Tools need to be suited for the audience I am working with.  Ideally, these tools will meet my needs AND theirs so that I am supporting something I actually use.  Makes it much easier to support.
- Some way to nudge people towards appropriate instructional design.  Especially those who have already gone through this process with me.

- How best to incorporate development for mobile in the least painful way possible.

- Is there a way to scale the support more efficiently and effectively.  Say....making it so that I am not as necessary to the process.  I like being needed and all, but at a certain point I won't be able to meet the demand alone.  Besides, I am thinking my move towards more self-service training and support in eLearning would better encourage the move towards self-service training and support in other areas. 

Tools, of course, are the easiest and most fun thing to tackle.

Yes, I am probably falling into the "shiny new thing" trap - but dangit, it's low hanging fruit and something I am in a position to address now.  The other stuff is still percolating.

I would be perfectly happy to continue with my Captivate program, but after rolling this program out to a number of users  - I am rapidly finding that this may not be the appropriate tool for them. 
The HTML5 thing also has me a bit worried.

I am sharing my "evaluation" spreadsheet to give you an idea of where my head is at.

It is not entirely filled in since I haven't looked at everything yet. 

I also left out the licensing and cost information since that's confidential stuff, and I don't deal with money around here.  I just beg others.

The Row headers are requirements and cost/licensing information
The Column headers are potential tools.
Tools that have been replaced or upgraded are in grey.

Hope this helps.

Tuesday, July 03, 2012

Has My Relationship with Mobile Changed?

Quick answer: no.

I had a chat with my Mom about mobile technologies during the Great Derecho Blackout of 2012.  (Mom and Dad had power, I didn't - great excuse to go visit the folks.)

She was lamenting how people (like my brother) get distracted by their cell phones when talking to you in person, how mobile technologies are a leash, how the expectation is that we are always on and always answering, and that this is fundamentally wrong.

Very interesting, considering she used to be a Sales Manager for a beeper company back in the 80s and has been the most technologically mobile person in the family up until my brother got his first real cell phone.

I've managed to manipulate mobile technology for my own purposes - a few old-school phone calls, texting a few close friends (slowly - I suck at mobile typing), the occasional answer search on the internet, and taking pictures.  Time spent at mLearnCon didn't change these patterns much. 

I still leave my phone in the car, or at home, and almost always on vibrate if I am with people.
If I know I am "on call" - I warn the person I am talking to.  Otherwise, in person trumps phone.
If someone calls me and I don't recognize the number (or am just feeling anti-social) - I don't answer.
Leave a message - I will get back to you...eventually.

Is this effective?  Efficient?  Erm....probably not.  Behind-the-times?  Absolutely.

Something about this technology has always brought out the Luddite in me.

GPS and location-tracking makes me even more nervous. 
My GPS is only on when I am using the Navigator function on my Android. 
And then, only under duress when I haven't printed out directions from Google Maps.

Anytime, Anywhere, 24/7 Access.
The mobile goal for my institution.
Good for others.
Not for me.

I hesitate when I find myself recommending something to others I am personally uncomfortable with.

Maybe I'm a little paranoid.  Maybe I spent way too much time in my History of Science and Technology days learning about unintended consequences.

But I wonder....at what price convenience?

Monday, July 02, 2012

Productivity is Like Porn

"I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["hard-core pornography"]; and perhaps I could never succeed in intelligibly doing so. But I know it when I see it, and the motion picture involved in this case is not that."

- Justice Potter Stewart, Jacobellis v. Ohio 1964
Picture from the Library of Congress
My organization is moving towards having more telecommuters as part of its work force.
Real estate in DC is expensive.  So is real estate in the suburbs.
The organization is trying to get non-student-facing staffers off the real estate.

The move from face-to-face cube dwellers to telecommuting home dwellers brings up a number of cultural and management issues.

One of the biggies is "How do we measure employee productivity?"

For whatever reason, that question doesn't seem like such a big deal when you can "see" them.
Are they sitting at their desk?   
Do they "look busy"? (Hooray Internet for a new tool in the "look busy" toolkit).
Do they act "busy"?

Since they can't see the employees when telecommuting - the managers now need to figure out what "productivity" means.  Easy when you are building widgets.  Harder when you are dealing with knowledge workers.

During one meeting - a staffer (not me this time) asked the Mucky Muck what they intend to measure when measuring productivity.  We essentially got a version of "I know it when I see it."

That's a little tricky to measure.

Gil Gordon wrote an interesting white paper on measuring productivity.

I liked the following breakdown (which he defines as "effectiveness" vs. Productivity):

- Quantity (how much gets done)
- Quality (how well it gets done)
- Timeliness (when it gets done)
- Multiple priorities (how many things can be done at once)

Fundamentally, they need to decide is what a "productive" person looks like.

Once they figure that out - they can then decide how to measure it and where to pull the data from.

I think that might make everyone just a bit more comfortable with the coming culture shift.