I have been thinking about this for several years now but some recent events have brought this to the forefront. The “camel meet straw” event was when our most recent course management upgrade was installed, it was extremely buggy with Internet Explorer 8, which had been installed on campus as a standard browser. Of course the CMS vendor was clear in their listing of supported browsers (and IE8 was not on that list). Still, we had to deal with MANY calls and frustrated users because they were trying to use their updated browser in our updated system and things just were not happy.
I see two major problems here:
- it is time-consuming and expensive to continually develop a product and test it against ALL browser flavors available now so the supported browser list stays “dated” for longer than end users want or need
- it is impossible to prevent end users from upgrading to the latest and greatest browser, (especially when Microsoft Software Update does the upgrade for the user)
So, I present the concept of the EDUbrowser.
It really is pretty simple. Take a browser engine like WebKit or Gecko and build your own browser around it. Using a plugin architecture (I know Gecko supports that – don’t know about WebKit), you can add features like HTML editing (like Xinha) , annotations (ala Scrapbook or Zotero), social networking options such as Flock has done and, perhaps, work with third party companies like Respondus to create optional secure browser features for online testing/quizzes much like Respondus LockDown Browser but within the EDUbrowser rather than using a totally separate product.
And, of course, you can build a toolbar that “brands” your school so you can also provide access to support links, school event information and more. Something like Conduit would do the trick
Plus, if the LMS vendors take the EDUbrowser and test it against their products, then it can be come the ONLY supported browser greatly simplifying their QA testing and verification as well as the local school’s own technical support.
Thus, you simply tell faculty and students that they must use the EDUbrowser. Our experience with the RLDB has been that students are fine with downloading and installing something they need for class, so I don’t think asking them to use this particular browser will be an issue (except for those who are attending class at work and cannot install something on their computers there – I can see that being an issue).
What else does it take to get the EDUbrowser out in the wild? What else would you add to it?
Here is a Ignite-style talk I gave on the Edubrowser at the D2L FUSION Unconference in July 2010