Sunday, September 18, 2005

ASU-TechPlan WIKI

Ok, so I spent a good part of the weekend knocking together the first version of the ASU-Tech Plan Wiki. At this point it does not even qualify as a skeleton, but if you read the Methodology post or listened to the podcast then you already know that I expect this wiki to be the vehicle for creating a strategic plan collaboratively, right out in the open, without the need for expensive committees.

Applications are now being taken for moderators. Of course, some of the folks listed as moderators don't even have accounts and haven't even accepted their commission, so its early days yet.

For now, prowl around and see if you can make head or tail of it. If you have a question, any question at all -- say about how the wiki works, or what pages to use for what, or whatever, -- then for the time being use the discussion or Talk Page associated with the main page to ask it. Someone on the moderation team will try to answer it as soon as we can.

Don't think you have to work alone. Put a team together, start working up some strengths, weaknesses, opportunities or threats for one of the sections and get things started. We'll be formatting on the fly, so put your best guesses out there. The destiny you shape could be your own.

More later, but its wicked late. I'm redoing a tamer version of the podcast for Working Group 1 on Tuesday. I'll let you know how it gets received and what I learn there.

One last thing. Caught the Quiet Boys at "Into the Bean" last Friday night. Personal favs - 'Lawyers, Guns and Money' by the Zev, and 'Folsom Prison Blues'. Another highlight was Darrel Huisch's version of James Taylor's version of 'Oh, Susannah'. A good time was had by all. Thanks guys.

3 comments:

Nancy September 18, 2005 at 8:39 PM  

Lovely wiki. Good start. I had a wishful thought about ASU's Portal before noticing the advent of the wiki announced here, and will go ahead and post the thought. (I imagine much of the wiki content may come in from this or other blogs.)

If one were daydreaming and not thinking much about how to actually do the thing, it would be nice if "Help" on the Portal or ASU's main Website, or both, were a Help resource not just for the Portal or Website, but for how one would do ASU things in general.

"Help" for computer systems has gotten pretty good over the years. My OS X help is easy to search and it's easy to find things by looking at the indexed topics, but it's also well organized to start with. I'd been thinking, "wouldn't it be nice if the Portal had personal mentors for students, there to help them find out how to get to the M.U. or the Liberal Arts building, or choose a dorm, or tell them how to register for classes or remind them to get their Program of Study signed?" It would be a cool mentor, not like Microsoft's dopey paperclip, but more like an older sibling or friend who could show you the ropes.

I don't think we're there technically yet. But short of sibling-level personalization, a really good unified "Help" system could provide much of the same functionality. By unified, I mean take the procedures, instructions and FAQs listed in hundreds of Web and printed pages ("How do I get admitted? What do all those course/building/degree codes mean? What's the quickest way to get to USB from the Art Building? What's the maximum number of hours I can register for? When do I need an advisor? What kinds of Financial Aid are available to me? What are the most popular classes on campus? Which MBA professors turn out the most successful students? Where are the best quiet study spots? Where can I go to work with a group on a class assignment? Where's the cheapest copy shop? What does that guy's syllabus look like?") and combine them into one "Help" system with a common index and a search function. It's easy to conceive of such a system, since it's like the "Helps" we use on computers all the time, but organizationally it would not be so easy. How would the sections be organized? Who would have the authority to update them? How would you decide what should go in "Help" and what should merely be pointed to (like "that guy's syllabus", probably) or discussed ("how to find a class/instructor's syllabus")?

Having asked the question, I wonder now if a wiki would work for something like "Help", where some areas could be confined to administrators (like "Student Info > Registration Info > Semester Registration Deadlines") and other areas could be open to all students, faculty, staff? Perhaps the monitoring job would be too much of a hassle, in that case?

Just thoughts. Sorry we missed The Quiet Boys and Darrel Friday night. It's nice to finish the week with music.

Nancy

Nancy September 19, 2005 at 3:27 AM  

The Way of the Wiki, and why we should contribute:

The wiki provides a transcendent opportunity to create something new, from scratch, totally collaboratively and with the speed of thought. It gives us a chance to write a large part of our own destiny.

Are you unhappy with "X" system because it's too slow, too clumsy, too chaotic, doesn't do what it's supposed to do? Write about it in the "Weakness" SWOT list in the appropriate area. Do you have a solution that would collapse three bad practices into one good one? Write it in the wiki. If there's no place for that kind of idea, make one. The wiki conforms to our ideas like water to a container. If you can't write like Emerson and maybe aren't so hot at spelingk, no worries: the moderator or some other wiki-bot will come along and clean it up, leaving the idea intact. Don't know how to structure something new? Just throw it in - honest! - and someone will come along later in an idle moment and casually fix the structure.

We've all had the experience of having our ideas seemingly ignored, then seen them surface only to benefit someone else. We've all had the experience of seeing rewards go to those who are visible through proximity rather than performance. But through the wiki and blogs, we are all equally proximate to the decision-making core.

No ideas are truly lost in the wiki and neither are the names of their creators. Unlike the creation of a Great Pyramid, commanded by a Pharaoh and "signed" by an architect, but built brick by brick by anonymous labor, the wiki records the contribution of every idea. Every brick has its bearer's name on it, logged in the wiki's page history. Maybe, when the plan based on this wiki is done, we could have a big old party and give prizes for Most Bricks Contributed and Best Wiki-Preener - just a thought - but more importantly, we have a chance to say How We Think Things Should Be, and not have the ideas lost in committee or hierarchy, but succeed or fail on their own merit. Wow.

"Wiki Memebot" Lee

Nancy September 21, 2005 at 7:37 AM  

"Data abstraction layer"... I wish everyone would read this good article about it. Sounds boring but the article is actually funny, and it clarifies one of administrative IT's most deeply-rooted problems. Lack of data abstraction creates pernicious problems for all large, venerable systems. An ERP will simplify our problem to some extent - for awhile - but not eliminate it. It's an overall architecture problem, a DBA/data administration problem.

How does this relate to the wiki? Mm... I put the link for the definition in the glossary? Also, I'm wondering if "Information Utility" is the best title for the current "Section 6" of the wiki. I understand that access to information should become like access to transportation, electricity, plumbing, and the other necessities of civilization; that information should be pervasive and should have the simplest possible interface (like a light switch or an on-ramp). But I'm not sure that the word "utility" conveys the need for an overarching system - an architecture, an umbrella, a sphere within which all functions are identifiable in a relatively short time. As systems become more complex, they need to share some kind of commonality that allows problem diagnosis and resolution. That commonality can include standards and protocols. Perhaps a security strategy could be shared. (Lord knows that networked systems brought with them a spaghetti-monster nightmare of semi-redundant control lists and inconsistently-applied rules, more than irksome to us old mainframers secure with RACF. But I digress... )

Defining that "umbrella" of shared functionality and standards is going to be enormously important to our ability to move forward into front-end simplicity/back-room complexity. Does anyone else have an idea what to call that thing, other than "utility" or "infrastructure"?

Nancy