<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet href="/topics-files/atom2xhtml.xsl" type="text/xsl"?>
<!-- This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers.
This is a 512 byte XML comment that one must put into XML Atom feeds
such that browsers like Firefox 2.0 and IE7 will obey the XSL stylesheet.
Everybody hates overbearing browsers. -->
<feed xmlns="http://www.w3.org/2005/Atom"
><title
>Blog@Case Topics: wiki@case</title
><link rel="self" href="http://blog.case.edu/topics/wiki@case"
 /><id
>http://blog.case.edu/topics/wiki@case</id
><category term="wiki@case" label="wiki@case"
 /><link rel="related" href="http://blog.case.edu/topics/wiki" title="wiki"
 /><link rel="related" href="http://blog.case.edu/topics/mainblog" title="mainblog"
 /><link rel="related" href="http://blog.case.edu/topics/case%20wiki" title="case wiki"
 /><link rel="related" href="http://blog.case.edu/topics/linkblog" title="linkblog"
 /><link rel="related" href="http://blog.case.edu/topics/blog@case" title="blog@case"
 /><link rel="related" href="http://blog.case.edu/topics/blog" title="blog"
 /><link rel="related" href="http://blog.case.edu/topics/syndicated%20feeds" title="syndicated feeds"
 /><link rel="related" href="http://blog.case.edu/topics/case%20branded%20templates" title="case branded templates"
 /><link rel="related" href="http://blog.case.edu/topics/google" title="google"
 /><link rel="related" href="http://blog.case.edu/topics/blog@case%20developments" title="blog@case developments"
 /><link rel="related" href="http://blog.case.edu/topics/failures%20of%20technology" title="failures of technology"
 /><contributor
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></contributor
><updated
>2006-08-05T22:42:46Z</updated
><entry
><title
>Collaborative Stats on Case Wiki</title
><link href="http://blog.case.edu/jeremy.smith/2006/08/05/collaborative_stats_on_case_wiki"
 /><id
>http://blog.case.edu/jeremy.smith/2006/08/05/collaborative_stats_on_case_wiki</id
><published
>2006-08-05T22:41:03Z</published
><updated
>2006-08-05T22:42:46Z</updated
><category term="case wiki" label="case wiki"
 /><category term="collaboration" label="collaboration"
 /><category term="mainblog" label="mainblog"
 /><category term="statistics" label="statistics"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>I did some more mining of the 
<a href="http://wiki.case.edu">Case Wiki</a> data. I did this before in 
<a title="Jeremy Smith's blog: Tipping Point for a Wiki to Become Self-Correcting" href="http://blog.case.edu/jms18/2005/12/02/tipping_point_for_a_wiki_to_become_selfcorrecting">Tipping Point for a Wiki to Become Self-Correcting</a>. This time, I was looking for the pages that the most different people have edited. Trying to rephrase that, I wanted to see the most collaboratively put together pages. The #1 was 
<a href="http://wiki.case.edu/Brief_Writing_Checklist">Brief Writing Checklist</a> with 28 different editors. #2 was the lengthly titled 
<a href="http://wiki.case.edu/Econ395_Richard_Shatten_Public_Policy_Case_Competition">Econ395 Richard Shatten Public Policy Case Competition</a> with 15 different editors. The top 4 breaks down like this:
<ol>
<li>
<strong>28 different editors</strong>: 
<a href="http://wiki.case.edu/Brief_Writing_Checklist">Brief Writing Checklist</a></li>
<li>
<strong>15 different editors</strong>: 
<a href="http://wiki.case.edu/Econ395_Richard_Shatten_Public_Policy_Case_Competition">Econ395 Richard Shatten Public Policy Case Competition</a></li>
<li>
<strong>12 different editors</strong>: 
<a href="http://wiki.case.edu/Freedman_Center">Freedman Center</a></li>
<li>
<strong>9 different editors</strong>: 
<a href="http://wiki.case.edu/ToDo">ToDo</a></li>
</ol>After the top 4, there are 7 pages with 8 different editors. That list includes 
<a href="http://wiki.case.edu/Email_Services">Email Services</a> and the enigmatic 
<a href="http://wiki.case.edu/B1IQ6P2_Main">B1IQ6P2_Main</a> page (&#8592; and "no," I can't discern really what they are doing and I don't know what "B1IQ6P2" stands for). There are 6 pages with 7 different editors, 17 pages with 6 different editors, so on and so forth. Here is a graph showing this (OpenOffice's graphing capability sucks, by the way): 
<a href="http://blog.case.edu/jms18/2006/08/05/number_of_pages_by_different_editors.jpg">
<img alt="number_of_pages_by_different_editors.jpg" src="http://blog.case.edu/jms18/2006/08/05/number_of_pages_by_different_editors-thumb.jpg" width="520" height="368" />
</a> Because I know 
<a title="Greg Szorc" href="http://blog.case.edu/gps10">Greg</a> is gong to ask for them, here are the SQL queries I used. The query to generate the pages with the most different editors is the following: 
<code>SELECT COUNT(DISTINCT(rev_user)) AS editors, page_title FROM revision JOIN page ON page_id = rev_page GROUP BY rev_page ORDER BY editors DESC</code> Then, to break the data down for the graph, I just manually compiled it by running the following over and over again subbing in a different number: 
<code>SELECT COUNT(DISTINCT(rev_user)) AS editors FROM revision JOIN page ON page_id = rev_page GROUP BY rev_page HAVING editors = 5,4,3,2,1</code></div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>IT End User Help Documentation</title
><link href="http://blog.case.edu/jeremy.smith/2006/04/08/it_end_user_help_documentation"
 /><id
>http://blog.case.edu/jeremy.smith/2006/04/08/it_end_user_help_documentation</id
><published
>2006-04-08T21:13:37Z</published
><updated
>2006-04-08T21:15:02Z</updated
><category term="Failures of Technology" label="Failures of Technology"
 /><category term="IT in Higher Ed" label="IT in Higher Ed"
 /><category term="case wiki" label="case wiki"
 /><category term="linkblog" label="linkblog"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="Gregory Szorc's blog - Revisiting Computer Help Documentation" href="http://blog.case.edu/gps10/2006/04/08/revisiting_computer_help_documentation">Revisiting Computer Help Documentation</a>
<blockquote>
<a title="RightAnswers: Products Self Service" href="http://www.rightanswers.com/products_selfservice.html">RightAnswers Self-Service</a> is over-marketed software... 
<a title="Case Western Reserve University" href="http://www.case.edu/">Case</a> is getting the raw end of the deal and I have a responsibility as a caring university member to share that observation.</blockquote>I've long urged people to put their end user system's documentation on the 
<a title="Main Page - CaseWiki" href="http://wiki.case.edu/Main_Page">Wiki</a>, and any chance I get, I urge people to move these "Help Scripts" to the Wiki. But I don't think the issue here is a matter of 
<a title="PerceptIS, LLC" href="http://www.perceptis.com/">PerceptIS</a> thinking they would lose money. "Don't attribute to malice what can be explained by..."</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Tipping Point for a Wiki to Become Self-Correcting</title
><link href="http://blog.case.edu/jeremy.smith/2005/12/02/tipping_point_for_a_wiki_to_become_selfcorrecting"
 /><id
>http://blog.case.edu/jeremy.smith/2005/12/02/tipping_point_for_a_wiki_to_become_selfcorrecting</id
><published
>2005-12-02T21:23:01Z</published
><updated
>2005-12-02T21:24:52Z</updated
><category term="case wiki" label="case wiki"
 /><category term="mainblog" label="mainblog"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>Commenting on 
<a title="RSS4Lib:: Campus Wikis and Wiki Authority" href="http://blogs.fletcher.tufts.edu/rss4lib/archives/000904.html">RSS4Lib:: Campus Wikis and Wiki Authority</a> and 
<a title="j's scratchpad: Subject of an Inaccurate Wikipedia Entry, Seigenthaler Speaks Out" href="http://blogs.law.harvard.edu/jkbaumga/2005/12/02#a4268">j's scratchpad</a>:
<blockquote>While pointing out 
<a href="http://wiki.case.edu">Case Western Reserve University's CaseWiki</a> on 
<a href="http://blogs.fletcher.tufts.edu/rss4lib/">RSS4Lib</a>, Ken wonders 
<a href="http://blogs.fletcher.tufts.edu/rss4lib/archives/000904.html">how large a wiki community must be before it becomes self-correcting</a></blockquote>Well, to speak about 
<a href="http://wiki.case.edu">our wiki</a>, it has yet to reach a behavioral level of self-correcting; and I can speak about our numbers. At this point, we have about 600 registered users to the wiki. At first blush, that may sound like a lot; but very few of the users perform more than one edit. Here is a chart I whipped up showing the users and how many edit/creates they have done: 
<a href="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_bar_chart.gif">
<img alt="wiki_edits_by_user_bar_chart.gif" src="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_bar_chart-thumb.gif" width="575" height="378" />
</a> Most users stop by, login (which grants them their first edit during the auto-generation of their 
<code>User:</code> page), and never actually commit an edit. But really, that's expected. The top 2 bars (I removed the data for the internal MediaWiki user) are 
<a title="Gregory Szorc's blog" href="http://blog.case.edu/gps10/">Greg</a> and myself, the administrators of the application. In pie chart form, you can really see how many of the edits we account for (we're the two big slices): 
<a href="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_pie_chart.gif">
<img alt="wiki_edits_by_user_pie_chart.gif" src="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_pie_chart-thumb.gif" width="528" height="361" />
</a> But at this stage of the game, with the wiki 
<a title="CaseWiki:History of the project - CaseWiki" href="http://wiki.case.edu/CaseWiki:History_of_the_project">still so young</a>, that's to be expected. I don't think the question of "when does a wiki become self-correcting" is in the total number of users as much as it is in the number of a certain "type" of user. After all, you can end up with 40k registered users; but if only 6 of them are ever doing any edits... Here are the same graphs again, but this time, I removed all of the persons with one edit and mine and Greg's data: 
<a href="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_bar_chart_abridged.gif">
<img alt="wiki_edits_by_user_bar_chart_abridged.gif" src="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_bar_chart_abridged-thumb.gif" width="575" height="378" />
</a> 
<a href="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_pie_chart_abridged.gif">
<img alt="wiki_edits_by_user_pie_chart_abridged.gif" src="http://blog.case.edu/jms18/2005/12/02/wiki_edits_by_user_pie_chart_abridged-thumb.gif" width="528" height="361" />
</a> Breaking that data down into some metrics:
<table border="1">
<tr>
<th># of Edits</th>
<th># of Users</th>
</tr>
<tr>
<th>100 or more</th>
<td>7</td>
</tr>
<tr>
<th>Between 20 and 100</th>
<td>16</td>
</tr>
<tr>
<th>Between 2 and 20</th>
<td>49</td>
</tr>
</table>Another way to look at that data is that 8% of the users account for 55% of the changes; 13% of the users account for 65% of the changes. So with those kinds of numbers, we have yet to reach a self-correcting stage. But I think those numbers are still soft because many of those persons play inside of "walled gardens." That is, they spend a lot of time editing their own pages (just a lot of times). There isn't a lot of cross-pollinization going on. Therefore, in conclusion, to summarize: I don't know. But at the point in time when the Case Wiki begins to exhibit self-correcting behavior (which I have no idea how to measure, so I'll just go with my gut feelings as I observe the wiki changes), I will make sure to do a lengthy blog post with plenty of data and graphs and analysis and such.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Wiki-fy the ITS Services List</title
><link href="http://blog.case.edu/jeremy.smith/2005/10/05/wikify_the_its_services_list"
 /><id
>http://blog.case.edu/jeremy.smith/2005/10/05/wikify_the_its_services_list</id
><published
>2005-10-05T22:07:11Z</published
><updated
>2005-10-05T22:09:21Z</updated
><category term="General Information Technology" label="General Information Technology"
 /><category term="it" label="it"
 /><category term="linkblog" label="linkblog"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="A to Z of ITS" href="http://www.case.edu/its/services/A-Zindex.htm">This</a>, in my humble opinion, is in dire need of 
<a title="Main Page - CaseWiki" href="http://wiki.case.edu/">wiki-fication</a>.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Case Wiki Search Results in RSS</title
><link href="http://blog.case.edu/jeremy.smith/2005/07/21/wiki_rss_search_results"
 /><id
>http://blog.case.edu/jeremy.smith/2005/07/21/wiki_rss_search_results</id
><published
>2005-07-21T20:53:01Z</published
><updated
>2005-07-21T20:50:33Z</updated
><category term="linkblog" label="linkblog"
 /><category term="syndicated feeds" label="syndicated feeds"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="CaseWiki:Feeds - CaseWiki" href="http://wiki.case.edu/CaseWiki:RSS_Feeds#Search_Results_Feed">Case Wiki Search Results in RSS</a> 
<em>WooHoo!</em></div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Mapping Blog@Case RSS Feeds on Google Maps</title
><link href="http://blog.case.edu/jeremy.smith/2005/07/06/mapping_case_blog_on_google"
 /><id
>http://blog.case.edu/jeremy.smith/2005/07/06/mapping_case_blog_on_google</id
><published
>2005-07-06T18:19:47Z</published
><updated
>2005-07-06T18:24:59Z</updated
><category term="Blog@Case Developments" label="Blog@Case Developments"
 /><category term="blog" label="blog"
 /><category term="blog@case" label="blog@case"
 /><category term="case wiki" label="case wiki"
 /><category term="google" label="google"
 /><category term="googlemaps" label="googlemaps"
 /><category term="mainblog" label="mainblog"
 /><category term="maps" label="maps"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>Here in 
<a href="http://wiki.case.edu/ITS">ITS</a>, we've begun some earnest talks on location based services. Location based services are hard to talk about. They are hard to talk about because they inevitably lead to discussions on fruitless services. Services that sound "cool" when you are sitting at a table talking about them, but in actuality, are of little use. Like "find restaurants near you"; such that, if you are in 
<a href="http://wiki.case.edu/Tomlinson_Hall">Tomlinson</a> and you log on to the 
<a title="MyCase" href="http://my.case.edu">Portal</a>, a little window widget says "you're near a Subway restaurant." See, right now, right in your head, you may be thinking to yourself, "
<em>ooooh</em>, that would be neat." No... it... wouldn't. It would be annoying. It's an example of information 
<strong>pushed</strong> at you. Information thrown into your face whether you want it or not. If I want to know what restaurants are nearby, I will 
<strong>poll</strong> for that information. All you need to do (and by "you", I mean a "service" or "set of services") is make sure it is easy to discover where I go to poll that service and make it as seamless an experience as possible. 
<strong>Push</strong> information == bad :: easy to find and easy to use 
<strong>poll</strong> information == good. But, that's a tangent. You can think about that on your own. What information is 
<strong>pushed</strong> at you (or is "interrupting" information) versus what information do you 
<strong>poll</strong> for; which do you like better; and how easy was it to find the place to 
<strong>poll</strong>. Etc. A phone call versus an email. A big blinky popup versus a targetted search for consumer goods. So, back to location based services. Or, the genre thereof. People have been playing with 
<a title="Google Maps" href="http://maps.google.com/">Google Maps</a>, and so have I. I want to be able to map people posting to 
<a title="Blog@Case" href="http://blog.case.edu/">Blog@Case</a>. To do this, all I need is to put location-based data in each blog's 
<a href="http://wiki.case.edu/RSS">RSS</a> feed and hook into the 
<a title="Google Maps API Documentation" href="http://www.google.com/apis/maps/documentation/">Google Maps API</a>. There is a pseudo-standard for including location-based data in 
<a href="http://wiki.case.edu/RSS">RSS</a> feeds, it's called 
<a title="worldKit :: easy web mapping :: RSS" href="http://brainoff.com/worldkit/doc/rss.php">geocoded RSS</a> and it, basically, looks like:
<pre>
<code>&lt;?xml version="1.0"?&gt;
<br />&lt;rss version="2.0" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"&gt;
<br />&lt;channel&gt;
<br />...
<br />&lt;item&gt;
<br /> &lt;title&gt;An example annotation&lt;/title&gt;
<br /> &lt;link&gt;http://example.com/geo&lt;/link&gt;
<br /> &lt;description&gt;Just an example&lt;/description&gt;
<br /> 
<strong>&lt;geo:lat&gt;26.58&lt;/geo:lat&gt;</strong>
<br /> 
<strong>&lt;geo:long&gt;-97.83&lt;/geo:long&gt;</strong>
<br />&lt;/item&gt;
<br />...
<br />&lt;/channel&gt; &lt;/rss&gt;</code>
</pre>So, mapping an RSS feed with that data becomes slightly trivial. Last night, I spent some time doing just that. Here is a mock up RSS feed &#8211; 
<a title="geocoded rss feed" href="http://blog.case.edu/jms18/code/googlemaps/rss20.xml">http://blog.case.edu/jms18/code/googlemaps/rss20.xml</a>. And, here is a stab at mapping that &#8211; 
<a title="Playing with Google Maps" href="http://blog.case.edu/jms18/code/googlemaps/">Playing with Blog@Case and Google Maps</a>. Of course, the real trick is getting that geocoded data into each blog's RSS feed. There are several ways I can do that. I can get the blog system to look up your latitude and longitude coordinates by your IP address, or I can offer a text box you can populate with a street address when you are creating an entry or it can be a check box that just says "I am in my dorm room" or "I am at work" and then lookup that information in the directory server. Much more thinking and playing to be done. And, obviously, combining this with being able to 
<a title="Gregory Szorc's blog :: Google Maps API + Case Wiki = Map of Wiki Entries" href="http://blog.case.edu/gps10/2005/07/06/wikicase_wiki_geotag">map</a> 
<a title="Main Page - CaseWiki" href="http://wiki.case.edu/Main_Page">Wiki@Case</a> entries will be equally amusing.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>New Case Wiki Skin</title
><link href="http://blog.case.edu/jeremy.smith/2005/06/22/new_case_wiki_skin"
 /><id
>http://blog.case.edu/jeremy.smith/2005/06/22/new_case_wiki_skin</id
><published
>2005-06-22T23:17:17Z</published
><updated
>2005-06-22T23:18:25Z</updated
><category term="case branded templates" label="case branded templates"
 /><category term="case wiki" label="case wiki"
 /><category term="linkblog" label="linkblog"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>
<a title="Main Page - CaseWiki" href="http://wiki.case.edu/Main_Page">Wiki@Case</a> has a brand new look.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Improving Wiki@Case</title
><link href="http://blog.case.edu/jeremy.smith/2005/06/21/improving_wikicase"
 /><id
>http://blog.case.edu/jeremy.smith/2005/06/21/improving_wikicase</id
><published
>2005-06-22T01:31:11Z</published
><updated
>2005-06-22T01:36:32Z</updated
><category term="case branded templates" label="case branded templates"
 /><category term="mainblog" label="mainblog"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>There are several things that need to be done to improve the overall feel of the 
<a title="Main Page - CaseWiki" href="http://wiki.case.edu">Case Wiki System</a> (and probably more things that I haven't thought of yet), but there is one large-ish one that is bothering me... the templates. Our first thoughts were that we would use the standard branded Case templates. 
<a title="MediaWiki development" href="http://wikipedia.sourceforge.net/">MediaWiki</a> skins of these were very nicely done for us by the ITG group in the 
<a href="http://wiki.case.edu/College_of_Arts_and_Sciences">College of Arts and Sciences</a>. There were a lot of reasons for choosing these; most namely, that the wiki pages would be easily identifiable as 
<a title="Case Western Reserve University" href="http://www.case.edu/">Case web pages</a>. Unfortunately, my experience (and other's) has shown that the branded Case templates are too limiting in this aspect. Quite frankly, 
<code>750px</code> (or so) is just too small of a width to contain a wiki page that has a lot of content &#8211; pictures and graphs, headings and sub-headings, etc. It just won't fit in the page nicely. So, I started thinking about ways we could retain the branding but make it more flexible so all of the different types of content would fit more nicely. Wacky ideas ensued such as having the "main" wiki pages follow the branding to the letter but other pages could have per-page or per-category skins that allowed them to be more flexible. Luckily, that idea existed in my head for all of three seconds before I realized how hokey that would be. The first "spoken aloud" idea was to change the Case branded templates ever so slightly to be a liquid layout. Remove the overall fixed width and let the page expand as necessary. This would retain the visual of the Case brand but allow for greater flexibility. But, I started thinking that could do more harm than good. It could dilute the branding... murky the waters, so to speak, of the Case templates. Now, I am thinking it is just time to change. What I would really like to see is something very, very similar to mock-ups 
<a title="Cool's blog" href="http://blog.case.edu/hac4/">Heidi Cool</a> did for a new set of 
<a title="Alternate Blog@Case Templates" href="http://www.cwru.edu/webdev/hactest/blogtests/indexb.html">default Blog@Case templates</a>. I 
<em>really</em> like that look and the colors, and do have plans to switch 
<a title="Blog@Case" href="http://blog.case.edu/">Blog@Case</a> over to them. Plus, it gives a consistent look to the 
<a title="Blog@Case Directory" href="http://blog.case.edu/directory">directory</a>. I think that those pages could easily be modified to give us a flexible liquid layout; one that would work very well for 
<a title="Main Page - CaseWiki" href="http://wiki.case.edu">Wiki@Case</a>.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Blog@Case, Wiki@Case... Oh My!  INFORMATION OVERLOAD!!!</title
><link href="http://blog.case.edu/jeremy.smith/2005/06/18/information_overload"
 /><id
>http://blog.case.edu/jeremy.smith/2005/06/18/information_overload</id
><published
>2005-06-18T19:31:31Z</published
><updated
>2005-06-18T19:30:53Z</updated
><category term="Weblog Tech" label="Weblog Tech"
 /><category term="atom" label="atom"
 /><category term="blog" label="blog"
 /><category term="blog@case" label="blog@case"
 /><category term="mainblog" label="mainblog"
 /><category term="rss" label="rss"
 /><category term="syndicated feeds" label="syndicated feeds"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>With the rise of 
<a title="Blog@Case" href="http://blog.case.edu/">Blog@Case</a> and 
<a title="Main Page - CaseWiki" href="http://wiki.case.edu/Main_Page">Wiki@Case</a> (and other upcoming services), you may begin to feel 
<strong>Information Overload</strong>. How can one keep track of all of the information being produced? What about other services that will be coming in the future? How does one handle all of this? I have good news in this arena. Each of these services heavily employ 
<a href="http://wiki.case.edu/syndicated_news_feeds">syndicated news feeds</a> such as 
<a href="http://wiki.case.edu/RSS">RSS</a> and 
<a href="http://wiki.case.edu/Atom">Atom</a>. Keeping track of all of this information can be done without having to constantly revisit these pages. You can use 
<a href="http://wiki.case.edu/news_aggregator">news aggregator software</a> to quickly and efficiently process this information. Read a previous entry of mine, 
<a title="Jeremy Smith's blog: The 3 Stages of the Internet" href="http://blog.case.edu/jms18/2005/02/10/internet_stages">The 3 Stages of the Internet</a>, for more information on 
<a href="http://wiki.case.edu/news_aggregator">news aggregators</a>. Additionally, you can place any content available via RSS into your 
<a title="Case Portal" href="http://my.case.edu">my.case.edu</a> portal. And, just to give you a little hint into the future, RSS will continue to be widely used by many of the future services offered by 
<a href="http://wiki.case.edu/ITS">ITS</a> and many existing services (like... I don't know... say mailing lists) will be revitalized to offer RSS feeds of their content. It's not 
<strong>Information Overload</strong>; it's 
<strong>Information Opening</strong>.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
><entry
><title
>Animate Case Wiki Changes</title
><link href="http://blog.case.edu/jeremy.smith/2005/06/17/animate_case_wiki_changes"
 /><id
>http://blog.case.edu/jeremy.smith/2005/06/17/animate_case_wiki_changes</id
><published
>2005-06-17T23:13:41Z</published
><updated
>2005-06-17T23:12:59Z</updated
><category term="HTTP" label="HTTP"
 /><category term="Programming" label="Programming"
 /><category term="case wiki" label="case wiki"
 /><category term="firefox" label="firefox"
 /><category term="greasemonkey" label="greasemonkey"
 /><category term="mainblog" label="mainblog"
 /><category term="wiki" label="wiki"
 /><category term="wiki@case" label="wiki@case"
 /><content type="xhtml"
><div xmlns="http://www.w3.org/1999/xhtml"
>There's a cool little 
<a title="mozdev.org - greasemonkey: index" href="http://greasemonkey.mozdev.org/">Greasemonkey</a> script for 
<a title="Firefox - Rediscover the web" href="http://www.mozilla.org/products/firefox/">Firefox</a> that lets you 
<a title="Wikipedia Animate" href="http://phiffer.org/projects/wikipedia-animate/">animate the history of the changes of a Wikipedia article</a>. I thought this was cool, and I wanted to use it on 
<a title="Main Page - CaseWiki" href="http://wiki.case.edu">Wiki@Case</a>. 
<em>Un</em>fortunately, it worked in a very limited manner. It couldn't do all the changes only the most recent two, and I hated all the default options. There was something broken in the 
<abbr title="Document Object Model">DOM</abbr> processing it was doing. 
<em>Fortunately</em>, it's just some Javascript. A bit of tweaking at the stuff, and I got it to work. 
<a title="Greasemonkey Script to Animate Wiki@Case Changes" href="http://blog.case.edu/jms18/code/greasemonkey/casewikianimate.user.js">Try it out</a>. If you're not familiar with Greasemonkey scripts, I'm sorry. Try 
<a title="Google Search: greasemonkey" href="http://www.google.com/search?q=greasemonkey">Google</a> for help. Oh, and there was no license attached to the original code. So, 
<a title="Dan Phiffer" href="http://phiffer.org/">Dan</a> (the author of the original code) if you are reading this and you're really against people doing derivative works just shoot 
<a href="mailto:jeremy.smith@case.edu?subject=Hey!%20Stop%20Using%20My%20Code!!!">me an email</a>.</div
></content
><author
><name
>Jeremy Smith</name
><email
>jeremy.smith@case.edu</email
><uri
>http://blog.case.edu/jeremy.smith</uri
></author
></entry
></feed
>
