Skip to main content

Husband, father, grad student, academic technologies, OER, trail running, biking, sleeping. In that order.




New experiences but with old tech

5 min read

 On a wall at our local church hangs a public telephone.  It is exactly as you remember phones from 20 years ago:  fastened to the wall, a long twisty cord, and buttons in the headset that you use to dial the number.  While standing there in the hall after our meetings allowing my better half to visit with each member individually, my 13-year-old daughter asks me, “Dad, can this phone do anything other than just call people?” I said, “No, besides people you can call a machine that will give you voice recording of up to the minute time and temperature for our area.”  To which she replied, “You mean like Siri?”.  Needless to say that really got me thinking about how we do things like call people on telephones, look up weather and time differently today than we did 20 years ago.  And while we have new technology like smartphones and Siri to accomplish those same things, underneath it all in many respects the infrastructure isn’t too much different now than it was then.

I had a similar realization this past week as I replaced an old sprinkler controller box at my home.  For the past few years we had problems with our sprinklers and I knew that the problem would need to be fixed at some point.  That point came last weekend and I decided to fix the problem once and for all.  The problem was that sprinkler heads in certain zones would only work intermittently.  I began trouble shooting by first replacing solenoids, then valve diaphragms, and then re-wiring the electrical connections.  Nothing worked and I was stumped and frustrated.  Finally, I decided to look at the controller box and discovered that certain ports were not producing enough voltage to properly run the valves.

 I bought a new sprinkler controller and proceeded to wire it and get it set up.  I knew I was in for a completely different experience when step #2 asked you to download the associated mobile app and connect it to my wireless network.  What?!  Setting up the individual zones was easy to do and the app asked me for nozzle types, soil types, sun/shade exposure, slope of yard, etc.  Next it asked me to connect to a local weather station so that it could monitor rainfall in the area and adjust watering amounts as necessary.  What?!  After specifying a watering schedule, it informed me that it would break up watering times for each zone automatically so that the water had time to soak in.  Lastly, I informed my Amazon Alexa of this new device so that I could activate watering using only my voice.  I was truly blown away.

 Like the example with the phone, the underlying infrastructure of the sprinkler system was essentially the same.  Same valves, same zones, same sprinkler heads, wiring, etc.  But, my experience with that system was somehow completely different.  What enabled my experience to be profoundly different?  For one, I was not required to be physically located at the sprinkler box and could activate it remotely from either my smartphone, or my Alexa.  Second, the application itself was adaptive in that it customized a watering schedule based on inputs about sun exposure, soil, nozzle types and even weather data.  Lastly, my sprinkler system—like my smartphone—is personalized to me and my own situation.  My neighbor could purchase the exact same device and have a completely different experience even though underneath it all the systems are pretty much alike.

 I share these examples to illustrate the similarities in the work we are doing at BYU to improve academic technologies.  The use of APIs, personal domains, and mobile devices allows educators to create new learning experiences for students that are adaptive and personalized.  It moves the control and motivation for learning from a central system to the individual learner.  The underlying systems (Student Information Systems (SIS), Learning Record Stores (LRS) and Learning Management Systems (LMS)) that are necessary to run a university are still there, but by building new interfaces that focus on individual learners allows you to focus on adaptive and personalized learning that can lead to increased student motivation and engagement.  This approach, just like the example of my sprinkler box, allows users (teachers and learners) to have exciting new experiences in the teaching and learning process.

Future blog posts will focus on specific areas that we are working on such as student learning dashboards, university APIs, personal APIs, personal Domains, experience APIs (xAPI) and learning record stores, and many more.  Thanks for reading!


LMS of One's Own

It's not much to look at right now, but the concept is appealing:  using Domain of One's own aggregate assignments and messages from different LMS' into a single view.  Pull together all my assignments into list view, or into a calendar view and allow me to manage those from a single location of my choosing.  No, I'm not asking for the elimination of the other tools--I will still use those to submit my work and communicate with teachers and classmates, but in the spirit of Indie Tech, Domain of One's Own, Sovereign Source Identity I want a learning space that is mine. is that place for now.  Again, not a final product by any means, but a stake in the ground to carve out my own space in a sea of LMS', Digital Learning Tools, etc.  Thanks to Glen Sawyer, Kristen Eshleman, Jim Groom, Tim Owens, Phil Windley, and Kelly Flanagan for getting this idea to this point.  


PLE and PAPI, nouns and verbs...

2 min read

A few of us at BYU have been researching, exploring and building prototypes for Personal Learning Environments (PLEs).  A PLE is a learning space that you own that allows you to pull in assignments, notifications, and other activities from different tools, websites, or resources.  Specifically, we are learning how to pull in information from different LMS' and represent the data in a single location.  Some LMS vendors have really good APIs, others not so much.  We hope to build a PLE that might serve as an interface into your Personal API (PAPI).  A PAPI is a tool that allows you share and import information into a respository that you control and maintain.  PLE + PAPI might allow you to submit assignments into an LMS as part of a class.  PLE+PAPI might allow you to share a portofolio of work with a potential employer--much richer than a few lines on a resume.  In a noun-verb metaphore a PLE is the thing (noun) that might allow you to act/share (verb) data from your personal domain, or space.  I think they go hand-in-hand--nouns and verbs allowing you to receive and share information.  I think this process is critical to learning.  More on that thought later.

A humble PLE prototype:



Lessons learned

I have learned a valuable lesson this past week.  The lesson is that I should not rely on companies, or instititutions to store my research, data, or information.  My data is my data and I should store that in tools, repositories and applications that I can control.  This is an aspect of sovereign source identity and a driving principle behind indie web applications like domain of one's one and known.  The symbol above is used by a company called, "mendeley", which is a research tool that allows you store, annotate and manage the many, many files related to graduate school.  Basically, Mendeley was storing all the research I have done for literature reviews, etc.  At some point a department at BYU decided that too many users were using the tool and they set out to fix it.  Without warning they randomly selected student accounts and deleted their access to many shared folders, kicking me out of access of hundreds of files.  I wasn't asked, I wasn't warned, just had the rug pulled out beneath me.  Supposedly, I should still have all those files and access to them, but of course I don't and can't.  Not a fan of institutional control.  I am new convert to the indie web movement.  Lesson learned!


BYU IT Executive 2016 Strategic Offsite

Great conversation today with members of Kelly Flanagan's IT Leadership team discussing strategic direction and initiatives.  Topics included:

What (are we doing?)
  • Cloud-based Compute
  • Cloud-based Storage
  • Network
  • User Identity (Domains)
  • Communications
  • Lifelong learning
How (are we doing it?)
  • DevOps
  • Domain Driven Design
  • APIs
Where (are these activities taking place?)

  • Event-driven architectures
  • Microservices
  • Student Information Services
  • Student Admissions
  • Ecclesiastical Endorsements
  • CES Initiative