jump to navigation

What does an LMS offer? March 8, 2016

Posted by ficial in brain dump, Instructional Technology, LMS.
add a comment

The spectrum of LMS use can be divided into three general realms: administrative, organizational, and pedagogical. Administrative functions fulfill needs relating to the non-academic overhead of giving and receiving an education: managing course enrollments, providing communication channels, collecting assignments, scheduling, etc. Organizational functions improve the management of information and resources related to instruction: providing access to information whenever it’s needed, placing information into useful, usable groups, searching available information, handle various formats, etc. Pedagogical functions expand and refine the tools that instructors and students can use in the teaching and learning process: asynchronous discussion forums, auto-graded quizzes with immediate feedback, limited-audience authoring experiences, collaborative creation projects, etc.

In the administrative realm, an LMS integrated with other campus information systems offers a clear improvement over doing things piecemeal and by hand. This gives a better experience for students and significantly helps instructors through greater reliability (and auditability), increased consistency of experience, reduced non-academic workload, fewer distractions, some automation, and enhanced versions of traditional tools. Making use of the administrative aspects of an LMS requires little to no work or input on the part of instructors or students; an LMS provides a large net gain in the administrative realm.

In the organizational realm, an LMS allows an instructor better control over how students receive their information for the course, more flexibility in adding, removing or rearranging information, a wider array of information that be be offered, the ability to front-load information management work (allowing more efficient use of time), and preservation of the information associated with the course. For students, an LMS offers a single place where course information can be found and processed, access to that information whenever it’s needed, and the presentation / arrangement of that information that the instructor has determined is most effective. For an instructor to make use of the organizational aspects of an LMS requires him or her to find or to provide information in an electronic format and to organize and to present that information using the tools in the LMS; for instructors an LMS typically provides somewhere from a small loss to a moderate gain in the organizational realm, depending on the information being managed and the instructors comfort with the tools. For a student, taking advantage of the organizational aspects of an LMS requires little to no work or input; for students an LMS provides a large net gain in the organizational realm.

In the pedagogical realm an LMS can offer tools and techniques that would otherwise be impossible or impractical. These can be subdivided into enabling technologies (such as the ability to deliver video, electronic slideshows, etc.) which allows an instructor or student to extrapolate traditional pedagogical methods into the digital world, and alternate technologies (such as asynchronous forums, virtual environments, instant assessment, etc.) which allow exploration of new pedagogical models. Making effective use of the pedagogical aspects of an LMS requires lots of hard work on the part of both instructors and students, but teaching and learning takes a lot of hard work without an LMS as well; the net gain or loss in the pedagogical realm is highly situation-dependent, though an instructor would not invest the time in pursuing this use of an LMS in a particular situation unless he or she had a reasonable expectation of a net gain.

Specific functionality could fall into more than one realm, depending on how students and instructors apply it.  While a given application could be assigned to a given realm, this realms concept might be more useful in a comparative role; e.g. posting a course reading is more pedagogical than posting a syllabus and more organizational than discussing the reading in a forum.

Due to its set of functionality in the administrative and organizational realms and to its integration with other campus infrastructure, an LMS is very useful  for campus organizations and groups in addition to course-oriented academic purposes – ideally an LMS works well for organizations and groups.

fixing a moodle cron problem – lastcron not updating January 26, 2010

Posted by ficial in code fixes, LMS, moodle, techy.
add a comment

I recently finished a section of code that’s supposed to send reminder emails to users once per day. Moodle has an interesting approach for how this kind of thing is handled. In brief, there’s a DB table that tracks how often a process is supposed to run and the last time it ran, and the moodle system has a single central cron job that runs once every five minutes or so and calls the sub-processes based on the timing info stored in the DB. In principle that’s a reasonable approach. HOWEVER, it turns out that main cron code was failing to record when each sub-process ran, so the sub-process was running EVERY TIME the main process ran. In my case this meant it was sending out emails every 5 minutes instead of once a day – not good.

It’s a bit strange, since the main cron code looks like it’s supposed to do that update:

if ($blockobj->cron()) {
  if (!set_field('block','lastcron',$timenow,'id',$block->id)) {
    mtrace('Error: could not update timestamp for '.$block->name);
  }
}

but for whatever reason that lastcron field isn’t actually getting updated AND no error message is being generated.  Perhaps the cron process in the block needs to return true very explicitly? Perhaps set_field is silently failing? Whatever the cause, it’s a serious problem.

The work around I found (in a timetable import script bug fix) was to explicitly update that field as a part of the cron sub-process.  So, after the emailing code I added:

$susblock=get_record('block','name','signup_sheets');
$susblock->lastcron=mktime();
update_record('block',$susblock);

and now everything is working as it should. It’s not ideal – the main cron process should be doing that lastcron update – but it gets the job done, it’s easy, and it won’t interfere if/when the main problem is fixed.

Planning and Managing a Technology Project, Part I June 5, 2009

Posted by ficial in brain dump, Instructional Technology, techy.
add a comment

I wrote this up as part of planning a workshop with the above title. I was going to wait until this was a ‘finished’ document, but it’s been about a month now and I haven’t gotten back around to it. So, here’s what I have, and I’ll post more on this when and if I get around to writing it.

How IT Fits In Standard Project Management

Generally, project management frameworks identify four main phases of a project: initiation/vision, planning/design, execution/development, and closing/deployment. Unless you’re in an IT focused job or company, an IT project is usually a sub-part of a larger project that’s using something like the above model. I’ll start by covering where IT (in general, not any particular person, group, or department) can fit in those stages, and then go into more detail about the IT piece itself.

Difficulties often arise because of three main issues. First, IT is a wide-ranging and specialized field of knowledge, which makes it hard for the larger project manager to understand it well enough to do detailed planning. Second, IT is often included only towards the end of the planning stage or the beginning of the development stage, which can mean delays and confusion in creation of the requirements. Third, IT development models can conflict with large project management frameworks.

Vision/Initiation

IT provides understanding about the technology’s capabilities, often revealing possibilities the you did not know existed. IT can also help you figure out what kind, if any, IT work you’ll need later.

IT gains an understanding of the larger project goals, which they may use directly if they’re implementing a portion of the project, or which makes them more useful if called in to help, find, choose, and communicate with other IT workers.

Not including IT at this stage won’t directly cause a project to fail, but can cause other serious problems. Incomplete understanding of technology capabilities can lead to a project trying to do too much, or too little. Also, there may be existing technologies that already fulfill some of the project goals, which if unknown can lead to unnecessary work and/or an under-used final product.

Planning/Design

From a larger project perspective, IT can give you an idea of the technology implications of various options you’re considering. IT should also be able to provide some idea of cost and time estimates, usually in ranges. Often times IT work will involve a fair amount of invention and research, so some degree of uncertainty should be expected in these estimates, but at least some ball park should be available.

IT has a very strong interest here, as the results of this will form the foundation of their own work. What IT is looking for is a requirements document of some sort,and IT work cannot usefully begin until this document is finished. The details of what’s in that document depend both on the particular project and the development model the IT implementers expect to use. I’ll cover the requirements document in more detail later. IT people will help here by asking the questions it needs answered to get started on their own piece, and by giving you enough information and context that you can usefully answer those questions.

Not including IT at this stage can easily cause a project to fail, generally due to mis-estimating time and or budget needs, or else through mis-communication with IT, leading them to create a product that doesn’t do what you need it to do.

Execution/Development

This is usually the stage at which IT goes off and works on it’s own piece. IT should provide regular, though not necessarily frequent, feedback and updates during this process.

IT is mostly done at the end of this stage, with one important exception I’ll get to later when I cover the IT development process.

If IT is not included at this stage, then you don’t actually have an IT project and you don’t need to worry about anything in this document :)

Closing/Deployment

Generally IT is minimally involved at this point, though they may be needed to turn on / make live / release something. However, at the least they should be notified that the project is live.

Understanding the IT Development Process

There are many different processes that are used in IT development, ranging from highly structured to extremely fluid. The particular process that’s used depends on the size of the project, the type of project, and the background and preferences of the individuals working on the project. Two broad approaches are the iterated/fluid process, and the staged/structured process – most developers use a blend of each, but will tend more to one than the other. You should get some idea from the IT people of the development model that will be used (this is something the IT people decide, not something you specify) so you know what to expect.

All processes (or at least IT workers) also use some common terms when discussing projects, which can be confusing and/or misleading to those not in IT. The foundation for all processes are the Requirements, so I’ll start there and then discuss them separately as they diverge.

Some Terms

Developer – a person working in computer code to create the product
User / End-user – a person who will me making use of the product once it is complete
Client – the person who who commissioned the product, may or may not also be a user
Code – the computer commands a developer writes to create the product
Content – information created or provided by users or clients; information manipulated by the code
Bug – a general term for a problem with the product
Alpha – the first working version of a product; usable, but buggy and has many features yet to be implemented
Beta / RC / Release Candidate – a version of the product where all features are implemented, but there are still bugs that need to be discovered and fixed
Beta-testers – users (often the client or provided by the client) who try to use the beta version of the product and report any problems they encounter
Gold / Release – version of the product that implements all features, fulfills all requirements, and has no known bugs
Object / Model – an abstract representation of a real world piece of information or thing
Business Logic / Business Rules – what should happen, as opposed to what can happen
UI / Interface – the way users interact with the product
Maintenance – on-going changes that need to be made to the product to accommodate bugs, security issues, or other environmental changes
Update / New Version – product changes that add new features and/or fulfill new requirements
Robustness – the product’s ability to handle the unexpected
Extensibility – the ease with and degree to which a product may be enhanced at a time after release
Customizability – the degree to which a user may change the product
Open Source – the code underlying a product is accessible, and also implies certain amounts of sharing, adaption, and that it is free
GPL – a particular licensing scheme that, among other things, makes a software product open source
Creative Commons – a particular licensing scheme that makes it easy to share content widely, but does not work as well for software

Requirements

Though the level of detail and specificity varies, at the core the requirements are a list of all the functions that need to be complete / implemented for an IT project to be considered done. A developer uses requirements both to figure out what to do, and to know when they’re done doing it.

More general requirements (e.g. “have a way to share information about upcoming events”) rely more on IT to decide best how to implement it. If you care about how something is implemented (e.g. events displayed in a calendar opn a web page), that should also go in the requirements or else you could end up with something unexpected (e.g. developer provides an email list). If the IT doing the implementing have been involved from the early stages of your project then you can safely have very general requirement and expect the IT people to choose the most appropriate implementation based on their own expertise and understanding. However, even in that case you should expect to have to answer questions, make decisions, and be available throughout the product development.

More specific requirements allow for a more complete hand off to IT for development, but at the cost of up-front planning and loss of flexibility.

An IT person not involved in the implementation can help you create appropriate requirements for a third-party developer to use.

One effective organization of a requirements document is to start with a very general goal at the top, then break it down in increasingly detailed sub-sections. Ideally for each requirement in addition to a description of what’s needed you say how important that requirement is, and how flexible you are about how it’s implemented.

Product Specifications / Design

Once the requirements are set, the developers then create a specification. The models diverge here in the formality and detail of the specification – a developer using the Extreme Programming methods might have a small, general specification that never exists outside her head and which changes as time goes on, while one using the waterfall method might create a detailed written document complete with UML diagrams.

In general, at this point the developer examines the requirements to determine what models will be needed, the business logic (how the models are allowed to interact, both with each other and with the user), and at least a general idea of the interface (what the product will look like, what controls may be used, etc.).

During this process the developer will also determine, at least roughly, the support / system requirement for the final product (e.g. this will need a machine with an internet connection and running the apache web server). They should provide this information back to you – and if they don’t volunteer it you should ask for it. Even if it’s full of jargon it will be useful to send to other providers to make sure you can use the final product once it’s delivered.

In general, you shouldn’t have to sign off on the design document, though you’ll probably want to examine the user-interface section pretty closely if you left that open in your requirements. You may want a copy early on to be shown that the developers are making progress on your project. It’s perfectly reasonable to ask for a copy of this design document before the developer begins coding, and you should insist that a copy be delivered along with the final product. However, you should also keep in mind that portions may not make much sense to a non-coder.

Iteration vs Stages

If the developer is using an iterated development process they’ll start by creating a minimally functional version of the product, then they’re refine and add to it. After each change they’ll test the product both for bugs and functionality, and if you’re available they’ll probably ask you to test it as well. This is one of the ways that an IT project can cause complications in a larger project – iterated development requires very frequent testing, feedback, and very good communication. One of the big advantages to this method over others is relative flexibility. NOTE: an iterated approach does NOT mean that requirements can be left unspecified, instead it allows flexibility in how those fixed requirements are met.

If the developer is using a highly structured process they’ll ‘freeze’ the design documents and then create a product that exactly (more or less – it’s not completely rigid) reflects that design. One of the big advantages of this approach is the clean hand off – once the requirements are fixed the client need not be contacted again until the alpha version is ready.

Release/Live/Gold

By whatever blend of development approaches is used, at some point the product will be considered ready to be made live. There are two criteria for when this point is hit. First, all requirements are fulfilled. Second, all known bugs are fixed. The developer will do some testing on their own, but will expect you to make some final sign-off that acknowledges those two things, and you should verify with your own testing that those conditions are met. You need to do the testing yourself not because the IT people are trying to slip an incomplete project past you, but because no matter how detailed the initial requirements document is, you’ll always have a better understanding of the requirements than the developer. Also, the developer does the testing from the perspective of someone who has significant pre-conceptions about what the product can and can’t do, so they often have blind spots about what to test.

Once the product is released you can move on to the next stage of your project, but it’s important to keep in mind that even at this point the IT portion of the project is not closed from their perspective.

Maintenance

When an IT project is ‘done’, it’s not really finished. Instead it moves from active development into maintenance/upkeep mode. Information technology products pretty much always need on-going work even after the project is otherwise done. The main reasons for this are:

  • Change in underlying technology – something on which the product depends changes, and so the product in turn needs work either to adapt to the changes or to use something different.
  • Bug discovered – heavy, live use has revealed unexpected and/or erroneous behavior, which must be fixed. Often this is tied to the above, or to a wider range of live environments than was tested / expected..
  • Security issue – this may or may not be a bug, but there is some security problem that needs to be fixed.
  • Incorporate feedback – after heavy use it’s determined that some changes need to be made. Surface changes (different colors, different arrangement of elements in a form, etc.) are generally considered maintenance, while functional changes or major UI changes would be treated as separate, new projects.

Regardless of the cause, from the IT perspective their project is still active long after the larger project is Done/Closed.

Maintenance changes are IT mini-projects; they have to be developed, tested, and released. One side effect of this is that even long after you’ve closed your project and moved on to different things, the IT people may contact you and ask you to do further testing. This is not an indication that the product they originally delivered was somehow incomplete, but that some maintenance work had to be done, and as before you will have a better knowledge of what to test than the IT people.

What You Should Get

When the IT people are done developing the thing, they’re going to hand it over you so you can finish your project. The ‘it’ that they hand you is a package that should, at a minimum include:

  • Finished Product – A working version of the product; this is the big one everyone expects, and sadly often all that’s actually delivered. Technically you could make do with just this (and many people do), but it’s well short of what you should get, and if you settle for just this then you (or your successor) will later regret it.
  • Source Code – This is the code behind the product. You’ll need this if you ever want the product fixed or enhanced.
  • Associated Content – These are the icons, images, videos, text, etc. that the product uses. You should get both the refined/finished versions that the product uses (e.g. the 30×30 icon), and the raw / original version (e.g. the 600×600 image that was shrunk down to create the thumbnail / logo / icon).
  • Design – This document explains how and why the product was implemented in the way it was. At the least it should have a general description of the product, plus a list of the requirements and the approach taken to fulfill each one; this document at least provides a high-level over-view of what the product does and how. It may also contain more detailed information on how particular tricky problems were solved.
  • Documentation – There are three general categories of documentation that the project may include:
    • Developer Documentation – This should ALWAYS be included. Part of this is a more detailed, technically oriented version of the design documents, which gives the over all architecture of the product and how all the pieces fit together (and why they do it that way). If there are particular technical interfaces / APIs, schemas, protocols, etc. they are also explained. Finally, there should be comments in the source code that elaborate on or describe particular sections as necessary. At the least, those comments should indicate what each function/method/subroutine/procedure/etc. takes, does, and returns if that’s not completely obvious from the name.
    • User / Help Documentation – These are the technical guides and explanations a user needs to use the product. They should be clearly written for a non-technical audience and should explain how to do all the common tasks, resolve all the common problems, and what to do if they encounter something unusual in the product.
    • Administrator – Often times a product will allow some user(s) to do more and more complicated things with it, ranging from configuration to usermanagement to fancier tools. These users need a guide similar to the general user documentation, but covering more tasks and in more depth. This should also provide much more guidance about how to resolve any problems, and guidance about how to help other users resolve their problems.

What’s Up with Lecture Capture at Williams April 22, 2008

Posted by ficial in brain dump, Instructional Technology, lecture capture.
add a comment

I just lead a small discussion for a few faculty and instructional technologists today over lunch about lecture capture what what would need to happen to get people to try it at Williams. I lead off with a quick slide show to define some terms and to provide some seed questions, then we just talked for about 30 minutes.  Here are the major points I took away from it:

  • to make this work we need some way of recording stuff written on a board (we could maybe emulate that with a tablet, sympodium, or smart board, but that’s not ideal)
  • the audio is important, but not the video of the talking head; point the camera somewhere more useful
  • look into dual-camera systems instead of just camera-projector systems
  • the non-fixed installation is better thought of as temporary / movable rather than truly mobile / portable (and, in general we need to find out more about the movable systems)
  • some faculty are probably willing to try it at some point
  • it might be a really good fit with tutorials for letting different sections see each other’s discussions
  • the ability to jump to / find particular points in a lecture is very important and maybe needs to be improved
  • some concern about students spending limited time re-listening to lectures rather than doing other course work

One of the big selling points seemed to be that people at other institutions were trying it and finding it useful. Here’s a set of links to some public info I found about that:

The short summary of all those is:

  • faculty and students who have tried a lecture capture system have liked it.
  • students self-report that it helps their learning
  • it has a positive impact on student grades, primarily helping the C and D students (it’s especially good for those who want to learn but are having difficulty with the material)
  • there’s little solid data about attendance rates, but anecdotal observation and self-reporting suggest that, counter-intuitively, it’s largely or completely unaffected

Upgrading Flash Streaming Server for Echo 360 (Apreso) March 24, 2008

Posted by ficial in Instructional Technology, lecture capture.
12 comments

Due to a relatively recent security hole in Adobe’s Flash Server 2 we had to upgrade the one driving our Echo360 (nee Apreso) system. It was a little scary to contemplate, but in fact went smoothly.

  1. Downloaded the latest version Flash Media Streaming Server 3  from Adobe – Flashmedia3_Int_Strm_ALP.zip – it was a bit disconcerting since this is about 160 megs and the previous version was about 8, but it’s OK.
  2. Ran a full back up of the host machine
  3. Unpacked the FMS zip file
  4. Ran the installer, accepting all the default choices and creating the same admin account and password as for the previous version (I don’t know if that’s strictly necessary, but seemed easiest)
  5. Edited the server configuration file (C:\Program Files\Adobe\Flash Media Server 3\conf\fms.ini) to set the VHOST.APPSDIR property (our Echo360 streaming folder is on a different partition from the FMS install)
  6. Restarted the FMS
  7. Tested a previously recorded presentation and it worked.
  8. Haven’t yet tried recording a new presentation, but given that the existing ones worked fine I don’t foresee any difficulties