Setting the System Requirements Bar Too High

Discuss the feature articles on the LDS Tech Home Page.
User avatar
McDanielCA
Member
Posts: 490
Joined: Wed Jul 18, 2007 3:38 pm
Location: Salt Lake City, Utah

Setting the System Requirements Bar Too High

Postby McDanielCA » Tue Oct 20, 2009 8:56 am

Setting the System Requirements Bar Too High was originally posted on the main page of LDSTech. It was written by Mark Nelson.
------------------------------------------------

I used to enjoy attending professional conferences: the inside scoop, the buzz of product announcements, tips and tricks, and the general enthusiasm of the crowd. It was hard not to get caught up in the excitement of it all. I couldn’t wait to get back home and try out all the new things I’d picked up.

But back in the office, I began to wonder how much of the conference really applied to my work. While I found great benefit in hearing somebody’s experience (positive or negative) in tackling a problem or learning the best techniques for doing something, the other information was more of a distraction.

Technology enthusiasts by nature tend to gravitate toward the cutting edge. We get excited about the latest product, language, platform, or standard that is going to make life oh-so-much better. There are many times, however, when the “tried and true” approach is a better path for our customers.

In my work at the Church supporting online learning tools and systems, I’ve found that it helps to keep a level head. New learning theories and industry observations spring up all the time. Everybody seems to know what learners “need” these days. But what are my learners really like and what do they really need?

Is it fair to compare Church employees with IBM, GE, University of Oklahoma, or any other group of employees? What about other learners who seek training from the Church, like family history consultants and missionaries, priesthood leaders, clerks, and so on? How are they different than Church employees?

Often, when I’m consulting with designers in various Church departments about which standards to use for e-learning development, they are surprised to hear that I am happy in many cases publishing e-learning courses using the AICC standard. “What?! Use a standard that was first introduced 20 years ago and hasn’t had even minor modifications in the last 5 years?”

Well, why not? I use FTP and HTTP and HTML on a daily basis. All of these standards have been around for decades. Perhaps they have gained wide adoption because they matured and went years at a time between some revisions. SCORM 1.2 and AICC CMI are widely supported by e-learning authoring tools and systems for that reason. When e-learning developers ask if they should use the latest e-learning standard to develop their next course, my first question is always, “What is it that you want to do in that standard that you can’t do in an older, more reliable standard?”

It is important to keep an eye on industry trends and even influence good standards and practices when we can. At the end of the day, though, I work for my customers, not the standards organizations and tool vendors. Most learners will not have a clue what standard or programming language I am using to deliver my materials, but they do know the difference between an exciting, predictable, and reliable experience and one that is frustrating, confusing, or intimidating.

The best customer experiences happen when things just plain work under a wide variety of conditions. This isn’t to suggest that we abolish system requirements and try to make things work in every scenario; quite the opposite. Support problems are more common when developers don’t know their target audience or don’t consult the system requirements before making plans to create something.

Content and Web developers should take a good, hard look at how to keep the minimum system requirements as low as possible, and then stick to them. This doesn’t have to be a tough exercise, but it does require deliberate action. For example, before I throw a simple PDF document out on the Web, I might ask myself questions such as these:

  • For which version of Adobe Reader (or a third-party PDF reader) did I publish this document?
  • Would it work as well if it were opened in Acrobat 5?
  • Am I using functions in this version of PDF that will not work in a previous version?
  • Am I okay with requiring my customers to download a 35-MB reader to view this document?
  • What if they don’t have broadband network access?
  • What if the latest player cannot be installed on a three-year old computer?
  • Am I limiting my audience to those who have the latest computers with the latest patches and software and a great network connection?
We should make our minimum system requirements decisions very carefully, consciously, and long before we are ready to release. My approach to meeting my learner’s needs changes when I think of the many different scenarios in which the e-learning may be accessed. If my materials will work with low system requirements, they will probably work in a variety of scenarios, some I haven’t even thought of. Mobile learners, Linux and Mac users, those employing assistive technology, or folks who may not know how to install software all benefit from lower barriers to entry.

While it is unrealistic to think that things will work perfectly for everyone, we can try to gauge our level of inclusiveness and how well we soften the blow of things not working by asking questions like these:

  • What percentage of my audience am I excluding by my current system requirements expectations?
  • How have I set clear requirements so people are less likely to fail and have a poor experience?
  • Have I considered progressive enhancement of my materials instead of just graceful degradation to allow those who aren’t running current computers to get the basic message from the materials?
Great training experiences do not require high system requirements. They do require technologists to put aside, at times, the shiny polish of cutting edge tools and standards, focus on the real needs and viewing conditions of their learners, and set a system requirements bar that is low enough to welcome a wide and varied audience.

Mark Nelson is an application systems engineer for the Church.

User avatar
mesmith
New Member
Posts: 26
Joined: Fri May 02, 2008 1:00 pm
Location: USA, Colorado, Strasburg

Postby mesmith » Tue Oct 20, 2009 10:22 am

I think you make a great point with this, but you have also missed a point of view. Cost! By adopting high system requirements we push people into complying with requirements they my not be able to afford. If you also take into account that some people will look at it as an obligation in order to be obedient to God then this takes on a more urgent feel. Take something as simple as the new FamilySearch. I know people in my rural ward that are taking on the expense of satellite internet in order to use new FamilySearch from home, "because they want to be good FH consultants". Then their old computer isn't fast enough so they buy a new one. Then Microsoft rolls out a new office suite, so they buy that to stay up with everyone else (ex. stake office distributes calendar in docx). I agree that we should lower requirements AND we should push toward the lowest cost. Most everyone wants to do their best in their calling but they shouldn't have to take on expenses that can be avoided. Doing things like designing web sites for low bandwidth, support most common browser standards (not ActiveX), using OpenOffice instead of MS Office, and being platform portable, can go a long way to reduce the financial impact that technology has on being an active participant in church (callings particularly). If we do it right, the solutions will even be portable to members overseas because the system requirements will be "low" and "low cost" for developing countries.

As an example that fits your area of work, a lot of training was done using PowerPoint (back in the day) before more sophisticated tools came along. With a little effort we even had quizzes with scores at the end to test a users understanding. That technology was simple and is widely available today, and at no cost if done in OpenOffice. Sure, it will lack a lot of the glamor that some of the more exciting tools offer, but no member (in the world) would have to spend any money in order to use the training.

My 2 cents.
Sincerely,
Marion Smith

lwheelr-p40
New Member
Posts: 1
Joined: Tue Oct 20, 2009 11:13 am
Location: Medicine Bow, WY, USA

Thank YOU!

Postby lwheelr-p40 » Tue Oct 20, 2009 11:19 am

I've been commenting a lot lately on some similar topics, pointing out that reliability to the end user and efficiency for the client is the top consideration. I loved some of your statements which echo how I feel about it. While many applications of these principles are different between small business clients and larger entities, the bottom line is getting the best performance for the dollar so that both end user and site owner benefit to the greatest degree.

Simpler is usually better.

Laura

techguy
New Member
Posts: 4
Joined: Fri Oct 10, 2008 6:17 am
Location: Cochrane Alberta Canada

Great Viewpoints Here

Postby techguy » Tue Oct 20, 2009 6:45 pm

I have been involved in technology for over 30 years. The most reliable circuits that I design use "old technology" and are a bit more in cost hardware wise but are much cheaper for the labor and troubleshooting prior to install compared to microprocessor based controls.

Over the years I have had many people laugh at my circuit designs but they work, they continue to work and I can still get parts for them. Many people that have supplied alternate designs on competing projects now have circuits with obsolete parts, have lost their staff over the years and now have to train in obsolete troubleshooting to keep customer projects going or need to replace entire systems with newer, available technology.

New technology really is great as many really marvelous advances have been accomplished. However, the ever present advancement of technology often is a concern for companies that need to remain conscious of customer costs, both initially and to maintain the system that was supplied.

As none of us can know the future with much certainty, I constantly ask myself " What would happen if ...." surrounding mostly hardware availability and how would I maintain the functionality if major components were declared obsolete and the new versions were no longer compatible.

It is important to exercise corporate responsibility and take care of our customers even if they do not know what all of the risks are. If we do our best, the Lord will take care of the rest.

james_francisco
Member
Posts: 76
Joined: Thu Feb 08, 2007 9:42 am
Location: Arizona
Contact:

Postby james_francisco » Fri Oct 23, 2009 9:16 pm

The choice of technology for a product needs to be driven by the target audience. If your product is intended for a high-tech audience, then is probably needs to have all of the latest gadgets and widgets in it to be competitive and to give the target audience the user experience that they want. And in some respects, that is an easy task.

Producing a product for the members of the church is a lot different because of the broad range of resources that may or may not be available. Because the end product needs to be useful to the member with a top-line broadband connection and one that has just a modem, the task gets much harder to make that product work for the member at the low end and still be attractive and useful to the user at the other end of the tech spectrum.


Return to “LDSTech Featured Article Discussions”

Who is online

Users browsing this forum: No registered users and 1 guest