Last week one of our mission critical systems hit a bump in the road and was offline a better part of the day. We have a web application called System Status that is used by the help desk to track the availability of such systems. Having resolved all the issues we left the building only to realize that we needed to update the System Status application to notify the help desk and end-users that the system was back online.

Three of us immediately whipped out our iPhones to access the site and change the status flag. At that moment it hit me, why on earth isn’t this optimized for mobile devices? Having found a practical place to experiment with the iUI framework, I set about creating a parallel mobile interface for System Status. This interface, which uses the iPhone interface metaphors, will allow help desk support staff to check and update the status of our systems while out in the field or away on business.

Here are a couple of screenshots to give you an idea of how the interface would look on an iPhone.

Rock on, Stewart.

So, my little experiment is to send portal usage stats out via Twitter. The updates are sent every two hours between 8am and 6pm, Monday through Friday. Thank you, cron! There are so many moving parts in this that I’m tempted to fire up OmniGraffle to illustrate it, but I’ll try with just words and see how it goes.

The portal has multiple servers running behind the scenes so that we can deal with lots of traffic. Each of these servers have their own set of user sessions. We can query these servers for their session information, and we do this every 5 minutes and stick the information in a database (thank you perl and mysql). We have another internal system that allows us to graph and browse this data, which is incredibly helpful in looking for usage trends. I wrote a small ruby script that uses the Twitter gem written by John Nunemaker to query the stats database and then post the information to Twitter. Scott was even so kind as to place a Wordpress widget in our theme (top right) to show the information pulled directly from Twitter.

Now, some might call this a frivolous exercise but that would be ignoring the fact that we have to push a lot of information around campus and we need to be looking more at using proper APIs and not just don’t batch dumps of data to be imported by some other system. Our systems need to talk, and more importantly listen to what other systems are saying.

The other day, we caught wind that Confluence had been described in a meeting as the “Chicopedia”. Now I’ll be the first to admit that “chicopedia” is catchy, clever, and a great way of explaining to people that Confluence is a wiki by playing off the name Wikipedia. That said, it could potentially lead us into dangerous territory if not given proper context.

The term “wikipedia” can be split into “wiki” and “pedia”. The former being a collaborative editing environment and the later being a body of knowledge. In conjunction, they accurately describe the site Wikipedia, which is an encyclopedia written by multiple authors in a collaborative environment. This is all fine and good.

However, applying that same dissection, the term “chicopedia” should mean “body of knowledge about Chico State”. This is applicable if you’re talking about a web page that talks about Chico State and it’s history but it’s not applicable when used to describe Confluence.

Confluence is not necessarily a “body of knowledge about Chico State” but rather a resource used by Chico State to collaborate within and between departments.

Why worry about this in the first place? To start, this pilot is less than 3 months old and still finding it’s feet. Right now it is important to manage expectations for what Confluence is and what Confluence can do. This enables us to increase the chances Confluence will be a successful and effective resource. We must not think of Confluence as a “magic bullet” solution for problems that Confluence was never meant to solve because we fear we’ll start to view Confluence as a failure.

We’d also like to avoid being too closely compared with Wikipedia and the “why doesn’t it look like this?” or “why doesn’t it work like this?” questions because they are two different products that have two different types of content and wildly different audiences. The similarities between Confluence and Wikipedia are that they both can be edited by multiple people. The similarities end there.

So please, try to avoid using the term “chicopedia”.

It’s been a long time since I’ve posted something to Institutional Knowledge as I’ve been buried in Ruby code working on our upcoming Omni Project; but Enough about that.

Pat pointed out an interesting link today on the College Web Editor blog about prospective students using Flickr to take virtual tours of campus. Remembering that I was apart of a Chico State group on Flickr I went and pulled up a map of campus and all of the photos of campus that have been geotagged. You can see the most interesting photos from the pool here and hopefully the group will be able to put together a more comprehensive picture of campus on Flickr in the coming months (especially with the fall colors around the corner).

Now, I’ll be the first to admit, when we developed these pages last year there was some heavy 37signals influence that carried through (bright colors, larger type, etc). However, we had a good justification for those decisions. CAS was launch simultaneously with the new Portal so we wanted to grab the attention of everyone clicking through the login. Now, after a year with the new Portal, it was time to make things a little more subtle and increase the connection with the campus.

To strengthen the bond with the universities online brand we adapted a similar background gradient which also helped contrast the white background of the login form. In addition, we included the Chico signature header and grey seal combination from the universities web template system. With the previous version, the only references to CSU, Chico were the Wildcat logo and text Wildcat Login.

Other changes include a crude pop-up div that explains what the username actually is. In addition, we added support phone numbers for Students and Faculty/Staff incase users have problems.

Hopefully the new design will roll out next week after graduation. For the time being, I’ll be tweaking the design and continuously running browser tests.

Without further-ado, CAS Version 2.

If we add a few classes to this existing structure (plus a few @span@s) we could make the site microformat compatible.

Bam! Microformat compatible.

But the first step in taking advantage of a microfomat is knowing of it’s existence. For that, we have Tails, a nifty Firefox extension that alerts you to the presence of a microformat. You do use Firefox, don’t you?

One of the first things that came to mind was WiFi hotspots on campus. With a little help from MapBuilders and the CNS website I was able to create Google Maps Mash of Wildcat Wireless Hotspots. In essences, this simply takes the map and coloring aspect of this PDF document and merges in the data for specific buildings

So while is nothing new or super-fantastic it is a new spin on old data. Not to mention, it could give a website that wanted to convey this data the ability to do so with a little more flare than just a PDF document of a campus map.

Check it out today at Campus Wireless!