I was looking through some old files from last year, and found a document I’d written about my attendance at the WebBuilder 2.0 Conference in December 2007. I wasn’t blogging back then, and this was originally intended to be an email to my boss with some ideas on the future development of our web portal. I didn’t even finish writing and refining everything I was going to, and it’s a good thing, because it quickly turned from a thoughtful summary into a lengthy rambling discourse. I ended up making a simple PowerPoint to share with him instead.
The conference was actually a good kick in the pants for me, since I wasn’t as aware of the Web 2.0 world as I should have been, and what a powerful tool it was becoming. It exposed me to the importance of collaborative environments, the current trends with the web, and really shifted my mind toward embracing Web 2.0 technologies. I thought the term “Web 2.0” was kind of stupid (actually, I still do) but I can acknowledge that it represents an important shift in how we perceive interaction and collaboration. I wouldn’t attend the conference again, because I pretty much got what I needed out of it, and from the agenda it looks like the sessions haven’t changed much, but I’m grateful for the opportunity I had.
I don’t even agree with everything I wrote in the following document anymore. My knowledge has certainly grown since then. It looks like I didn’t understand OpenSocial, and I’m not entirely sure where I was going with the document storage idea. I also didn’t have a decent approach to social/learning networks — this is still an issue which is going to be difficult to tackle in our district. We had just launched our blogging system using WordPress MU, and were gearing up for deployments of our Moodle system and WeberTube. I’m anxious to see how widely these two services are used now that we’ve launched them.
I do, however, still think that our portal should take a cue from customizable widget-based sites like iGoogle, Netvibes, or Pageflakes. We are creating a new MyWeber portal from the ground up, though we’ve altered our course a little and are now going with a non-Java route. One thing I don’t like about many SISs is that you can’t even see a demo of it unless you have an account set up. How is this any sort of incentive to sign up for the system, if you can’t see an idea of what it’s about? This is why I would like to have both a public face and a private face to the next MyWeber. The public face anyone could visit and create a temporary customizable view and watch WeberTube videos, read district and school news from an RSS widget, look up a specific teacher’s public course assignments, look up Google Maps-based boundary maps for their school, and anything not containing sensitive information. The private face would let appropriate users see student grades, lunch account balances, transcripts — basic stuff for an SIS — but also let them view and write blog posts or leave comments on posts, make or take Moodle quizzes, upload videos, create podcasts, make a calendar, cast votes in a class poll, or anything else we make available.
THE FOLLOWING IDEAS WERE DATED DECEMBER 11, 2007
The [WebBuilder 2.0] conference was immensely useful. There was a tremendous amount of information geared toward developers, designers, and supervisors seeking to bring their web presence into the Web 2.0 world. I wish they hadn’t scheduled so many simultaneous seminars, as I would have liked to attend more of them, but I have uploaded all the conference slides to http://www.justinreeve.com/webbuilder/agenda.html.
Following is a selective summary of my notes, with some ideas on how to best direct our future portal development.
Web 2.0 is a model for a collaborative, user-friendly, socially networked web. Ajax has largely made this possible. Any evolution that takes place in web-based applications in the coming years will be derived from the Ajax framework, services-oriented architecture, and Web 2.0 philosophy. In other words, what has been dubbed “Web 2.0” is not just a fad. It will continue to shape what the future of the web will look like.
Web users now want to be able to do more than just find information. They want to participate and help shape the web. They’ve come to expect that web sites should provide collaborative and social networking opportunities, simple interfaces which mimic desktop applications, and mashups to enhance their experience.
DASHBOARD
I’m convinced the proper setup for the next major version of MyWeber will be the customizable dashboard view, which integrates all our applications into one place. The integration would include simplified Java-based translations of the PHP applications we have in place. While the same PHP backends for WordPress, Moodle, etc. would remain, the portal will provide a simple framework to accomplish basic tasks, such as:

  • Viewing assignments for a class.
  • Adding a new blog entry.
  • Uploading a video to WeberTube.
  • Taking a Moodle quiz.

In addition, widgets would be available for all the other functions we have and then some, e.g. user searching, progress reporting, podcasting, video streaming, taking surveys, etc.
MASHUPS
We’re already adopting most of the technologies that are needed to stay up to date on the current trends, and to enable our users to have the kind of interactive experience they expect. We need to decide what goals we want to accomplish, and what applications will help us reach them. Being able to integrate the different applications together is key.
Mashups are web applications that help integrate different sites together, combining data from other sources into a single, integrated tool. For example:

  • A single “Videos” widget in the portal could grab relevant videos uploaded to Moodle, WordPress, WeberTube, YouTube, TeacherTube, and even the Video Portal if we want, and display them all seamlessly in MyWeber, so the user never has to question where they come from.
  • When a user hovers over the name of a school or event in the portal, a Google Map could instantly pop up, and the map could give them the location. We could even let them enter their street address, and keep a list of addresses on file for the user, so they can receive directions to the school/event from wherever they are.
  • A teacher could have some photos on Flickr they want to share with their students in Moodle as part of a lesson plan. Rather than force them to manually download each photo, a Flickr mashup could connect to their account, let them select a group of photos, and automatically transfer them to Moodle, their blog, a whiteboard (mentioned below), or any other web-based service.

AJAX LIBRARY
Ideally, the user should never have to reload the page, except when they first log in. This can be accomplished through a combination of Ajax and modal windows. The recommended way to develop an Ajax application is to use an existing Ajax library, since otherwise there’s a host of issues to worry about with getting Ajax to function properly. I’m planning on using ICEfaces or Oracle’s ADF Faces since they provide all the basic functionality that I think we’ll need to accomplish this, plus they shift the load more to the server than the clients. LightWindow may be useful for popups such as progress reports, user details, transcripts, and so on, although ADF Faces has modal window support already built-in.
SOCIAL NETWORKS
There is one major feature we’re missing, and that’s social networking. Users have to come to expect a social networking application in the new generation of web applications. When they can shape the web sites, they have a more enjoyable experience. This means they will keep returning, and recommend the site to others. A social network can be anything from seeing a simple list of other people who are logged in, to having full-fledged forums where you can directly interact and, more importantly, collaborate with others on various projects. It also includes being able to participate in surveys, leave comments on songs or videos another user has uploaded, and anything which contributes to a shared user experience.
I don’t know if there’s an easy solution for us. We’ve addressed the issue of giving students, parents, and teachers access to a social network in varying forms before, and security concerns always seem to come up. Perhaps when employees use the forums, they could opt to be a volunteer moderator, or maybe we could put each student on a probation period once they sign up (e.g., all their posts are moderated for one month and at least 20 posts) while we make sure they aren’t using the system inappropriately. We could also require parental consent before a student can use any communication system. In other words, the parent would have to first activate an account, and then be given access to logs of their students’ correspondence.
We could have forums for users to interact with other users. Different types of groups could be set up, e.g. a teacher-students group, an administrator-administrator group, a teacher-tech group, a tech-parents group, and so on. We could convert a forum backend to a real-time RSS-based chat-style display, for simplified viewing in the portal.
Another route would be a selective user-based system. Let users talk to a select group of other users in the simplest form possible. Since this format is basically an instant messenger with a buddy list, we could set up a Jabber server for all the portal users, including parents, and develop a web-based interface. Employees could talk to their co-workers, teachers could host online parent-teacher conferences, department heads could hold online Q&A sessions, and students could talk to their friends. And none of the data need be viewable to those who aren’t allowed to see it, all of it would be logged, and anyone could set up their own unique group of portal users to communicate with.
Users could also use their cell phones to send text messages to the portal in this way, to contribute to a group discussion. We might want to also consider integrating other social networks into our interface, such as Yahoo! for Teachers using Google’s OpenSocial.
Whatever the answer may be, and if it’s not overly idealistic, creating a social network for all our users will be one of the best assets of the district.
COLLABORATION
It would be invaluable to give our staff and students access to a portal-based teaming and conferencing system, particularly something with a collaborative whiteboard and a document sharing system (e.g. Hiveboard). A couple provisions are in order:

  1. Others would need to be able to see exactly who’s editing the whiteboard, and
  2. A moderator (such as a teacher) would need to be able to prohibit access to specified users. All correspondence and collaboration should be savable and exportable to some simple form, too.

There may even be a way to tie in the online whiteboard with Smartboards, so combined with our audio streaming server, students at home can follow the lesson along with the in-class students.
BLOGS
Integrating a social network into a site is one of the best ways to get people to use the site, and our blogs are a good step toward this. The next step is to provide a blog aggregator. The portal should include a widget which aggregates all the blog RSS feeds relevant to the user by default, such as all blog feeds for a student’s teachers, or the technology blog for employees, and lets the user add any other blogs to the aggregator they want.
Our blogs should also have some easy statistical information associated with them, a simplistic version of MeasureMap, if you will. This way users can see right off how popular they are, and with any luck employees will be encouraged to use them more frequently.
Since users don’t always want to just go hunting through the content, a great way to bring all these together is to let users search through the blogs (Technorati is a good example of a blog search tool), as well as their Moodle courses, events, and so on.
CALENDAR
Every school regularly puts their events into the Groupwise calendar, and many departments do as well. There’s no reason not to include a calendar on the portal, and to provide each user a customized view of events relevant to them. A student should be able to see when the next holiday is, when the next football game is, what’s happening at the next assembly, and employees should be able to see when department meetings are being held, and so on. The calendar could also be merged with users’ birthdays for optional display, or perhaps each user could set up a list of friends and share information across calendars. What a user is able to see on the calendar should be customizable, and they should be able to import any public events they want into Groupwise, or another iCal-based scheduling system.
INTEGRATED DOCUMENT STORAGE
There should be a central filesystem for storing all staff (and possibly student) files. We have this already with the wwwstaff volume we’ve set up for the portal, but right now uploaded content for WordPress, Moodle, etc. stays on their own fileservers. The solution may be as simple as creating soft-links and mounts from our other web sites to wwwstaff, but more likely would involve some crafty filesystem manipulation and some way of identifying the type of information. An even simpler solution may be to have a process that goes out and identifies all the pertinent files on our web servers, then stores necessary linking data in XML or a database.
The benefit of doing this would be that ALL our documents would be indexable and searchable.
MOBILE DEVICES
Creating a mobile version of the portal is becoming increasingly necessary. While the portal is currently viewable on PocketPCs, it is not at the point I’d like it to be just yet, and it can be much, much better. The rate of growth of mobile web users is outpacing that of standard web users. More 16 year-olds now want an iPhone rather than a car. The next generation of phones will take their cue from the iPhone (Google Android has already started down this path) and future phones will provide full browser and full Ajax capability. I don’t think it’s necessary to focus on the iPhone just yet, but this focus should be reevaluated in a year.
We should concentrate on the older smart phones and PDAs and concurrently develop a version of the portal best suited to them. With some good development practices in place, it will be easy to make a mobile version of MyWeber v8 alongside the regular portal. We can include features like leaving text messages to a web service on the portal (such as a teacher’s blog, or on WeberTube, through an SMS message.
There are many possibilities involved in “mobilizing” the portal. A few examples follow:

  • Many of our teachers give a simple assignment to “Leave a comment on my blog.” Rather than require students to log into a computer, they could simply send a text message to the teacher’s blog, and the comment would be posted. Enabling text message input could be extended to other services, too, such as a portal-based conferencing utility or social network.
  • Students and employees could use the teaming and conferencing system directly from their phone or PDA.
  • Teachers could send a reminder to students that a homework assignment is due. A student could set up their phone to receive notices like this.
  • WordPress has a plugin that lets you support multiple template types, which would let any of our employees enable their blogs for mobile devices.