Headings: !!Proposal: !!Functions !!Participants: !!Steps !!Use Cases: !!Examples: !!Articles: !!Potential Software: !!Notes:

UCLA Knowledgebase Proposal & Planning Notes: ^

Design and develop an information bank or knowledgebase to help faculty, staff, students and campus help desks get accurate, current info about technology, administration and library solutions in this increasingly interdependent environment. We'll need this for the classweb consortium, SAKAI Pilot, Wireless, ISIS, Sophos, and other cross-campus projects.

Basically, we would create a new feedback mechanism where faculty and staff can get help without having to understand the increasingly complicated, highly networked campus technology infrastructre.

By assigning staff to monitor, moderate and even research answers, we leverage our staff expertise much more broadly. It is much easier to point someone to a well-written explanation or tutorial or step-by-step guide, than it is to write it anew.

Functions ^

Participants: ^

Steps ^

Use Cases: ^

Shared writeups or tutorials.
One department writes up a tutorial or detailed instructions for a common app, and another department wants to use it. The link to the off-site writup just becomes part of the answer, with the caveat to let us know if the link fails.
A three hour search through MSDN finds the solution to an obscure problem.
If that problem and solution is added to the knowledgebase it can save another tech support person from making that same 3 hour search.
Report on Empty Searches.
Daily reports can be made for knowledgebase searches that came up empty, and then we can either adjust meta tags to make appropriate answers show up for that search, or we can add this to the list of answers needed.
A student or faculty member reads an answer in the knowledgebase and has a correction or addendum for their particular system.
A COMMENTS link at the bottom of each page would allow that. And a report on recent comments can be used to look for edits that need to be made.

Examples: ^

Articles: ^

Potential Software: ^

  1. Andy's PHP Knowledgebase Andy's PHP Knowledgebase using MySQL is a database driven knowledgebase management system. It includes bookmark friendly URLs, Q&A, easy search with browsing by category, article submission, a powerful administrator interface and a professional and attractive interface. aphpkb Review Notes
  2. phpMyFAQ - good possibility. phpmyfaq Review Notes
  3. The Knowledgebase The knowledgebase is a tool to help you build a knowledgebase. The knowledgebase is organized into various topics. Users ask questions pertaining to certain topics. The questions/answers are browsable by keywords. The data is stored in a relational database - MySQL. _ It's slightly dated and there are probably others out there, but try this on for size. It gets high marks from the freshmeat rating system... - Steven C. Williams stevewil@glo.org 24 Feb 2004_ kbase Review Notes
  4. Lore ($99)
  5. http://www.knowledgebase.net/ - $
  6. Live chat software that's all done via PHP/MySQL and works with web browsers. The listserv was for University Web Developers, and someone was asking how to put undergraduate counselors "live chat" online cheaply and easily. Here's an example of its use at Bradley Univ. http://admissions.bradley.edu/freshman/ See two links on right side. This is the software, and it's commercial, but not outrageously priced. http://www.phplivesupport.com/ I particularly like the storage of the transcripts and the integrated knowledgebase.

Notes: ^

14 June 2005 Mike Franks: 18 June 2005 Prof. Francis Steen, Comm Studies: (email posted by Mike Franks)

The question is how to pitch it -- a general search engine like IU's, or a set of recipes aimed at learners.

For my purposes, I use google for unanticipated problems -- on the assumption that someone else may just have run into it too. Yesterday I solved a problem with my cousin's printer in Norway by following a discussion in New Zealand -- they had had the exact same problem. The chances of someone else at UCLA having run into the same problem is too small to be interesting. Of course this is Linux, which might change the argument, but I'm not sure it really does. Take your argument of the person who spends three hours researching a problem and then passes it on to a UCLA database. Well, the reason he had to spend three hours may well be that the problem is infrequent, so chances are nobody will run into it at UCLA. The number of unpredictable problems is astronomically large and the problem can't be solved locally -- a massive world-wide search engine will beat us hands down.

On the other hand, I need recipes for my students and sometimes for myself for overcoming predictable problems. This is where I would draw the distinction. The predictable we can build for, aggregate solutions, and target our audiences. Here I would very much appreciate help to offload my classtime and my own effort. Really explicit instructions for how to create a web page, for instance, would be really useful -- customized for BOL and our software. Even they would need frequent updates. Also a way to pool people's experience would be good.

Even a well-organized and stocked set of howtos is a lot of work to put together and to keep current. A wiki is actually not a bad format for this -- it can also help create a community.

20 June 2005 Phil Phillabaum, Arts and Architecture: (posted from email by Mike Franks)

My helpdesk deals mostly with administrative computing. We also support the setup of faculty machines, get them connected to email, and help them when hey need it.

One problem I forsee is instructions covering step by step access to administrative systems. It seems like there are going to be all kinds of documents that people won't want public. This could really help central groups like AIS distribute information. It would be nice if units like AIS could post things not in "draft" form (as it says in your quick write up) but limit the audience to IT folks. Tie it into the CSC database, let them grant access to help desk staff.

That's my 2 cents.

20 June 2005 Mike Franks meeting with Ricardo Garcia, CLICC:

21 June 2005 Ricardo M. Garcia, CLICC: (email posted by Mike Franks)

As per our conversation yesterday, here were a couple examples of things I was thinking of:

Branded Articles: Dell has something like what I was thinking in their community forum (depending on the implementation of a knowledgebase, they might not be so dissimilar)... See link and attached screenshot (in case you're not a registered dell member)

I could see this type of branded response having the same type of look in a semi-public (public browsing/authenticated authoring) knowledgebase. It also seems a natural fit for something showing department designation (SSC vs. CLICC vs. etcetera).

I was unable to find the Symantec one, though the design I was thinking of was similar to the dell site example.

While searching through the Symantec site, though, I did notice they have a couple of nice features such as ?DocumentIDs (which I'm sure are a standard kind of offering in a knowledgebase product) as well as a ratings system (Does this document answer your question: "Yes", "No", "Maybe, need to test", and "None of the above"). They also had an option to submit specific suggestions for improvement (which is nice if we are tracking authors) and language translations for key documents (see link, or attached screenshot 2:). I don't know if these features would be of interest to campus, but they might be nice!

Ricardo

23 June 2005 Paul Phillabaum, Arts and Architecture: (email posted by Mike Franks)

> Desks that have "bought in" at least to the concept, and put your name as a contact?

Sure, it's a good concept. The implementation will be the interesting part. :)

I see your point about different access levels. Keep it open and see how it develops. 

> Also, there's the question of who can post articles. I really want low overhead without a huge central admin process. What do you think of this:


> Approach #1:
> - let anyone at UCLA who can login through ISIS post articles, but their
>    name, status (staff, student, faculty) and dept. affiliation shows up
>    (none for students. I don't want to show their majors for fear of
>    Registrar concerns.)
> - the 43 Help Desks can create a list of their student workers who should
>    be allowed to post
>
> Approach #2:
> - let anyone at UCLA post, but unless they show up on UCLA
> Payroll in some way, their post gets put into a PENDING pool for some
> admin to approve it.
> - the 43 Help Desks can create a list of their student workers who should
>    be allowed to have their posts go up immediately
>
> Any other ideas? I'm sure there are other approaches.

Posting approach #2 doesn't seem to meld well with the low admin overhead you want. It will also restrict student access, and there will probably be a lot more students posting than faculty/staff. So I would definitely lean toward #1.

23 June 2005 Jose Hales-Garcia, Statistics: (on phone with Mike Franks)

23 June 2005 Patrick Burke: (on phone with Mike Franks) 23 June 2005 Martin Simon, Physics and Astronomy: (on phone with Mike Franks) 29 June 2005 Prof. Tim Groeling, Comm. Studies: in conversation with Mike Franks 5 July 2005 Jim Williamson, OID: in conversation with Mike Franks 7 July 2005 Julie Austin, SEASnet: in conversation with Mike Franks 8 July 2005 Met with Zoe Borovsky, Annelie Chapman, Stacey Rosborough: 8 July 2005 Rose Rocchio: 8 July 2005 Stephen Schwartz: 11 July 2005 Terry Ryan: brief conversation 11 July 2005 demo of eLibrarian by Tim Carlson and Eloisa Borah: 12 July 2005 Esther Grassian: 12 July 2005 Prof. David Sears: 19 July 2005 Peter Blase: 19 July 2005 Jeff Baughn - Bruin Online: 19 July 2005 Charles Kim - ISSR: 19 July 2005 Libbie Stephenson - ISSR Data Archives: 20 July 2005 Tim Carlson: 20 July 2005 Michael Mitchell - ATS Statistical Consulting: 20 July 2005 Aaron Seligman, CCPR: 20 July 2005 Lucas Lee, Economics: 21 July 2005 Edson Smith, Mathematics Computer Consulting: 21 July 2005 Scott McKnight, Law School Help Desk: 22 July 2005 Suzanne Stinson, Software Central: 22 July 2005 Eleuteria Hernandez, Chicano Studies Department: 22 July 2005 Hubert Ho, History Computing: 22 July 2005 Robert Kilgore: - will add notes later

22 July 2005 Rose Rocchio - SAKAI Pilot:

25 July 2005 Dawn Canfield - Psychology Solution Center: 25 July 2005 Judy Justus - External Affairs Help Desk: 25 July 2005 Scott Harvey - Network Operations Center: 25 July 2005 Mike Quirk - CTS Telephone Repair: 25 July 2005 Jackie Reynolds - AIS: 26 July 2005 - Gwen ?McCurry - CTS: 26 July 2005 - Darryl Itagaki - MCCS: 27 July 2005 - Rick Stearnes - CTS Student Technology Center: 28 July 2005 - Kaya Mentesoglu - International Institute: 27-28 July 2005 - Jim Carter - Math: (via email) 
Date: Wed, 27 Jul 2005 10:50:55 -0700 (PDT)
From: Jim Carter <jimc@math.ucla.edu>
To: Mike Franks <franks@ssc.ucla.edu>
Subject: Re: let's talk about making a UCLA Knowledgebase (fwd)


> ---------- Forwarded message ----------
> Date: Thu, 21 Jul 2005 15:53:54 -0700 (PDT)
> From: Mike Franks <franks@ssc.ucla.edu>
> To: "Smith, Edson" <edson@math.ucla.edu>
> Subject: let's talk about making a UCLA Knowledgebase
>
> Please take a look at this very rough writeup of a plan for a UCLA
> Knowledgebase, and then let me know when I might talk with you about it.
>
> http://www.sscnet.ucla.edu/consortium/index.pl?KnowledgeBase


This concept is interesting.  I may not be the best person to make comments
on it because I'm not on the front line helpdesk, but here are a few points
off the top of my head:  (Sorry for the mixed metaphor -- think Dilbert :-)


For software: it sounds like you're building a "wiki".  Check out software
under that keyword.  http://www.wikipedia.org/ is a big and famous Wiki
operation.  But I have no hands-on experience managing one of those.


MF: I've been using wikis with my student programmers and the few committees I'm on for several
years, but no, I don't think that's appropriate for the knowledgebase. I trust everyone on the
committees, but not everyone at UCLA.  I'm thinking more of a database of text questions and
answers. The permissions would go like this:


 - anyone at UCLA who can login through ISIS and is even partially
   employed by UCLA is allowed to post answers. Their name and dept. will
   show up on the post. They can go back and edit their post, and check
   a box to be emailed if someone comments or modifies their post.


 - anyone at UCLA who can login through ISIS can add a comment to a
   posting, but their name and dept. will show up.


 - the 43 UCLA Help Desks can designate staff as moderators. Moderators
   can edit or remove ANY post, but their name and dept. will show up.


 - anyone can anonymously suggest questions that should be answered.
   Though if this proves to be a problem, we can back off and make these
   question suggestions limited in viewing to the moderators. Or, limit
   to a UCLA login to suggest a question.


JC: Agreed, the social concept of a wiki is "useful grafitti" which is not
appropriate here, but I was thinking of the preprogrammed facility to post
new articles and to add content.  I wonder if there's a wiki program whose
user identification component is sufficiently non-(nonexistent) that it
could be adapted to do what we want?






Alternatively, or as a supplement to the wiki's own search feature, I've
had good experience with HTDig as a general purpose small scale search
engine.  http://www.htdig.org/


MF: I really don't want to build a content management system. Major content will reside on dept.
sites, and the knowledgebase answers will link there. So I don't think we need a file based
search engine. If I don't find something better, I plan to build it in PHP and MySQL and MySQL's
search facilities are pretty good.


JC: Response #1: the strength of a search engine is full text indexing, like
what Google does, without relying on the content provider having
useable keywords in the right places on the input form.  A SQL engine can
do no better than a serial search of the entire corpus, while there are
tricks such as trigram vectorization which the search engine can use to
good effect.  (I don't know if HTDig uses that particular technique, but it
does something magical and uses plenty of disc space to do it.)


Response #2:  If the corpus is nonlocal, a serial search is impossible
anyway.


Response #3: This is what HTDig is made for: you sic it on a prespecified
list of root URLs and it crawls through them, everything not password
protected (unless you provide the password, which is what we're doing for
one index of internal documents).  HTDig doesn't care if the corpus is on
your own web site or elswhere.




While it's likely that some of the software will run on Windows, you're
going to have a whole lot more freedom of action if your server's OS is
Linux.  (But no glitzy GUIs, awww.)


MF: I'm with you there. I've been using Solaris for years. My main job is the class websites in
Social Sciences. http://www.sscnet.ucla.edu/classes/.
We can host this until it gets huge or taken over.




Helpdesk people don't put enough articles into our own departmental
knowledge base.  Having them make two writeups will be like pulling teeth.


MF: That's a question I should have been asking. How many departments have their own knowledge
bases. I'm hoping to subvert them with a much more useful campus knowledgebase or work out a
data export arrangement or API.
CLICC has a knowledgebase, but much of it is private. Ours will be entirely public, so they'll
only want to share some of theirs. What is yours built on?


JC: We're using Perfect Tracker http://www.avensoft.com/pt7.html




Another important point is that this is aimed at Help Desks Staff first, then Staff Groups, then
faculty and students. The logic is that if it serves Help Desks well, it's already accomplishing
a lot. And they'll be the ones to keep it going. And we can experiment more with the Help Desks
as our first audience.




I wonder if there could be a XML ontology that could be grafted onto the
departmental K.B. software, so new articles could be uploaded automatically
in a useable form to the central database, either by department push or by
central suck.


MF: I'd be very interested in working on that.


Several commentators mentioned Google searches, and how outsiders spotted
and viewed UCLA departmental writeups as a result.  Sharing our knowledge
with the world community is good, and is good use of our bandwidth.  It's
also good for our people to use the world resource.  I hope you can read
Polish, because the Polaki often have good answers!


MF: Nope, but I see Brazilian stuff every now and then on the PHP programmers list I'm on. 
And I read Portuguese, slowly.


Your reference "Community Knowledge Sharing in Practice: The Eureka Story"
was very interesting.  


MF: I should read it then.


However, your major problems are going to be getting
departmental helpdesks to feed tips to the center, and getting them to
consult the central resource regularly.  


MF: Agreed. That and getting answers to give their context clearly.


Xerox had a unified organization
and multilayer escalation machinery to keep these functions tied together.
Your situation is much harder.


MF: Yup, but the real key is the data mining you can do once it's in place. I hope that will prove
enticing and interesting to the moderators and Help Desks. And encourage them to fill in gaps.
 - what are the big questions today?
 - what questions are coming up empty? Do we not have answers, or should
   different keywords be added to an answer to get it to match?
 - what questions aren't being searched? Should they be advertised better?


I'm also hoping to search out FAQs all over UCLA and encourage their owners to allow us to
compose questions with answers that link to them.


That could be a contest, what is the hardest to find information at UCLA, and where did you find
it?  Or, most interesting information?  For example, dialing 1223 on a campus phone will tell
you what phone number it has. (I'm sure there's more interesting info than that.)


What do you think?


James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@math.ucla.edu    http://www.math.ucla.edu/~jimc (q.v. for PGP key)

28 July 2005 - Alan Wood - Design|Media Arts Lab Help Desk:

28 July 2005 - Kathleen Copenhaver - Registrar's Office: 29 July 2005 - John Talbert - URSA Online Help Desk: 29 July 2005 - Sam Brown - Arthur Ashe Help Desk: 1 August 2005 - Max Kopelevich - Physical Sciences: 10 August 2005 - Slobodan "Jovca" Jovcic - OID, formerly GSEIS: 11 August 2005 - Jason Frand - Anderson Computing: 
Date: Thu, 11 Aug 2005 15:06:27 -0700
From: Jason Frand <jason.frand@anderson.ucla.edu>
To: Mike Franks <franks@ssc.ucla.edu>
Subject: Re: UCLA Knowledgebase


Hi Mike,
Gabe Ruiz runs our faculty support operation and would be your contact.  It would be great if we
could all share documentation and such on systems we commonly support.  Thanks for putting this
together,
jason

11 August 2005 - Zoe Borovsky, Center for Digital Humanities:

12 August 2005 - Gabriel Ruiz, Anderson Computing: 24 August 2005 - Libbie Stephenson, ISSR Data Archives: via email 
Date: Wed, 24 Aug 2005 16:01:32 -0700
From: Elizabeth Stephenson <libbie@ucla.edu>
To: Mike Franks <franks@ssc.ucla.edu>
Subject: Re: let's talk about making a UCLA Knowledgebase


Great - just had another thought - we might also want to include something that helps users 
understand what they can reasonably expect in terms of "help"  - sometimes there are high 
expectations that can't be met, or the user is asking for help on something that we do not 
cover in the archive, or we don't have the resources to do it.


What this project can bring out is the idea that we are in a relationship between help/services
and users - and that it is always moving along, improving, adjusting, etc.  That's how the use 
of technology in the way you propose is helpful because it is not all one way. 


I also think there may be places where different knowledge sources have the same information 
to share but perhaps in different ways or there may be chances to collaborate to expand on 
or improve the knowledge base by collaborating with other units.  It might even result in 
some resource sharing or savings ... maybe that is expecting too much?
best, libbie




At 03:51 PM 8/24/2005, you wrote:
      Libbie,


      Thanks. Glad you like it.


      At this point I'm looking at setting up a proof-of-concept in the next few weeks.


      Mike Franks        


      On Wed, 24 Aug 2005, Elizabeth Stephenson wrote:


            Date: Wed, 24 Aug 2005 15:48:50 -0700
            From: Elizabeth Stephenson <libbie@ucla.edu>
            To: Mike Franks <franks@ssc.ucla.edu>
            Subject: Re: let's talk about making a UCLA Knowledgebase
            Hi Mike,
            yes, I know it has taken me a month to read and get back to you - I liked what I saw
            and the compilation of everyone's comments was interesting.  So, where are we now
            with this?
            best, libbie

8 September 2005 - Mike Franks

12 September 2005 - Robert Miles, OID ITS (Information Technology Services) Help Desk 23 September 2005 - Sarah B. Watstein, Associate University Librarian for Research and Instructional Services 5 January 2006 - Mike Franks - Update 15 March 2006 - Mike Franks - Update 21 March 2006 - Mike Franks - Update 28 March 2006 - Mike Franks - Update 

- Ryan and Mike Lee - KB
  Rails 1.1 released, and Ryan updated it on his Powerbook
  Julie is updating Lighthttpd to newer version that fixes a problem with file upload.
  Also upgraded Ruby to 1.8.4 (from 1.8.2) 
  Then Ryan will upgrade Rails.
  On his machine he has 
    - can add a person
    - can change their level
    - can add a question
    - can't view it or add answer yet

31 March 2006 - email from Ryan 


The UCLA Knowledgebase is in early development.


Here’s what it CAN do:


1. add topics/questions
2. answer topics/questions
3. a very simple search, that searches the answer of the question (not the title yet)
4. I refer to a topic/question and it’s answer as an article. Articles are versioned
5. you can view versions of an article
6. you can tag an article


There are four roles.


1. level1 – students
2. level2 – staff
3. moderrators
4. administrators


-As of right now there’s no difference between level2-staff and moderators
-administrators have the ability to change the roles of a 
particular user (only Mike Franks and Mike Lee are administrators so far)


Here’s what you CAN NOT do:


1. comment
2. view a list of questions you didn’t submit. You can search and then view. but there’s no handy list yet
3. you can’t revert to a version
4. you can’t search tags or titles
5. you can not delete articles
6. you can not do anything that’s not listed under the things you can do


 URL for development environment hidden for now.


http://kb.ucla.edu and http://knowledgebase.ucla.edu will be 
used for the rails production environment which is not yet set up.


if there are any bugs, post them here: URL hidden for now.

4 April 2006 - Mike Franks - Update

11 April 2006 - Mike Franks - Update 12 April 2006 - Mike Franks - Update 28 April 2006 - Mike Franks - Update 3 May 2006 - Juan Tan - School of Public Affairs


Last edited Wednesday, 3 May 2006 at 16:40 by Mike Franks