Data Gathering Report:

ICS Web Site Information Needs of the

Professor User Group

Team Members: Bryce Carder

Nina Fan Andrew Trieu Miao Wang

ICS 205: Spring 2002 Professor Alfred Kobsa

2 / 21

Table of Contents Introduction ..................................................................................................................................... 3 Methodology ................................................................................................................................... 3 Data Analysis .................................................................................................................................. 4

Data Requirements ...................................................................................................................... 4 Course Information ................................................................................................................. 5 Contact Information ................................................................................................................ 7 Faculty Intranet ....................................................................................................................... 7 Policies and Procedures........................................................................................................... 8 Administration and Support .................................................................................................... 8 Faculty Profile ......................................................................................................................... 8 Data Accuracy......................................................................................................................... 9

Functional Requirements........................................................................................................... 10 Search Function..................................................................................................................... 10 Automated Web Surveys/Questionnaires.............................................................................. 10 Calendar and Scheduling....................................................................................................... 10 Prerequisite Checking ........................................................................................................... 10

User Requirements .................................................................................................................... 11 Usability Requirements ............................................................................................................. 11

Improved Navigation Structure............................................................................................. 12 Consistent Look and Feel...................................................................................................... 12 Provide Advanced Information ............................................................................................. 12

Conclusion..................................................................................................................................... 13 References ..................................................................................................................................... 13 Appendix ....................................................................................................................................... 14

Interview Questions................................................................................................................... 14 Interview Summaries................................................................................................................. 14

Interview 1............................................................................................................................. 14 Interview 2............................................................................................................................. 16 Interview 3............................................................................................................................. 17 Interview 4............................................................................................................................. 18 Interview 5............................................................................................................................. 19 Interview 6............................................................................................................................. 20

Data Analysis Spreadsheet ........................................................................................................ 21

3 / 21

Introduction In this study, we performed qualitative research to elicit information needs from users of the ICS web site (http://www.ics.uci.edu). The user group that we were assigned was the faculty member community within the ICS department, which consists of three types of professors. The types are described as follows: 1) professors who teach and research, 2) lecturers (who just teach), and 3) professors with administrative duties (i.e. Chair, Associate Chair). In our field research, we attempted to gain the perspective of all the identified types of professors by interviewing three professors, two lecturers and one professor with administrative responsibilities. Another interesting classification amongst the professors became obvious only after conducting a few interviews was their length of tenure with the ICS department, which in our study ranged from 7 months to 27 years. What is the purpose of this study? As one might expect, a user centered approach to designing an interactive product/system, like the ICS website, requires the understanding of users, user needs and tasks. Through the process of gathering a particular group of users’ requirements of the ICS website, we will be providing this document as reference for current and future designers of the website. Thereby, building on the identified user needs, these developers can perhaps produce a set of stable requirements or refine their current set to better serve the interests of the professor group that uses the ICS website. Our research is intended to provide more detailed insight than the typical response from users, which is, “from my prospective, I just want to get the information (from the ICS website) very quickly following certain links”, which tells a developer nothing new. In the next section we describe our data gathering methodologies. Following our Methodology section we describe our findings in what we call our Data Analysis section. Within the Data Analysis part of the paper we categorize our findings into requirement types, including data, functional, user and usability requirements. In each type of requirement we identify information needs that were elicited in our research. Finally we conclude with a bit of discussion about our research efforts and provide recommendations based on our experience.

Methodology Our initial plan was a three-pronged approach of gathering data/information needs that included 1) semi-structured interviews (with a contextual spin), 2) a focus group and 3) follow-up questionnaires. However, our initial plan also realized that a focus group and questionnaire would only be done if time permitted, which unfortunately it did not. So our research consisted of semi-structured interviews, which on average lasted approximately 20-30 minutes each. Each interview was conducted in the interviewee’s office in order to allow for observation of how each person used the web site within the context they would normally do so. We began each interview by introducing ourselves and by describing the reason for our interview (i.e. the project we were working on). This was followed with some warm up questions, like how long the user has been with the ICS department and what classes they taught or other responsibilities they held. The bulk of the interview consisted of one closed and three open

4 / 21

ended questions, which progressed towards our final goal of the interview, which was observation of what the interviewees used the ICS website for on a normal basis. From the observation we hoped to run into anomalies and missing data requirements that the professors would not have thought of had they not been looking and interacting with the web site. In all of our interviews we developed a partnership relationship with the interviewees, where we were not directing the responses of the interviewee’s but instead were collaborating with the users to understand their needs in terms of their work. With their permission, we taped (audio) each interview for further analysis. Both our interview questions and detailed summaries of our interviews are included in the Appendix section of this paper. As stated before, we did not conduct a focus group or do questionnaires due to time restrictions; however, given enough time we still may not have done them for a few reasons. First, we initially thought that a focus group would allow us to gain a consensus amongst professors on what information was important, but this came out naturally in our interviews. Furthermore, professors are very difficult to schedule interviews with, and getting a group of them together at one time would probably be near impossible. The questionnaires probably would not have worked either because they would require time and initiative on the part of the professors that have no vested interest without appropriate explanation (which cannot effectively be done via email). Nevertheless, our semi-structure interviews provided ample information needs and are described and analyzed in the next section.

Data Analysis In this section of the paper, we have identified information needs and classified them in terms of four types of requirements. Data requirements are intended to be information about the type of information, quantity, and accuracy of the content. Functional requirements deal with the interactive functions that are performed during use. User requirements are those information needs that are specific to our user group, which consists of highly educated computer science professionals. Lastly, usability requirements are discussed, and pertain to the effectiveness, efficiency, utility, and learnability of the website. (Preece)

Data Requirements The data requirements capture the type, volatility, size/amount, persistence, accuracy, and value of the amounts of the required data. From our interviews, it was evident that our interview participants have spent quite a bit of time visiting the ICS website and other related University websites. Since the ICS website acts as a portal to many other areas of the University, at times we may mention useful information that is found elsewhere, but is important to our user group because their means of finding it is via the ICS web site.

5 / 21

We have broken down user data requirements into subsections in which give brief descriptions and analysis. The order in which they appear in this subsection is by the priority we view them in, based on the number of responses asserting the requirement as an information need.

Course Information Perhaps the most important type of information for professors to find is course information. This includes the scheduled time, location, and size of a class, as well as the classes they are scheduled to teach each quarter. This information is available, although in many formats and across multiple websites. Professors are only concerned with course information in the context of teaching. Therefore, mixing degree requirements and course offerings created frustration because from the links themselves professors could not tell what they were going to get. In Figure 1, the Course Information page on the ICS web site is displayed. This is a page that professors use to get their information, but as one can see they have to wade through extra data that only pertains to students. Furthermore, it is not clear whether the user has selected “Graduate Education”, “Undergraduate Education” or “Student Affairs Office” in order to get to this information. Our first data requirement is to have a course information page that is professor specific; that only contains links to information that professors would find helpful.

Figure 1: Course Information on the ICS Website

(http://www.ics.uci.edu/academics/courses/index.html)

6 / 21

In many of our interviews professors would use the ICS website to go directly to the “Searchable Schedule of Classes,” which is part of the Office of the Registrar website. An example of important data that professors look for is shown below in Figure 2, which shows the classes that Professor Kobsa (not an interview candidate, just used as an example) is scheduled to teach during Spring 2002. Duplicating this data on the ICS web site is redundant and not an expectation of the user group we interviewed, however, a bit of integration through techniques such as predefined queries into the Registrar’s page would be useful. An example of a predefined query is show all ICS classes being taught by a professor or in a specific quarter, where the ICS web site lists the names of the professors or the quarter and the user makes a selection from the ICS web site that is fed into the Registrar.

Figure 2: Example Results from Searchable Schedule of Classes

(http://webster.reg.uci.edu/perl/WebSoc) Another data requirement was to provide links to the course home pages whenever possible. An example of this would be making the course descriptor, in Figure 2, “I&C Sci 205” a link directly to the course home page. The registrar page is just an example, but this could be done on the ICS website from course listings such as the “2001-02 Schedule of Instruction” page (http://www.ics.uci.edu/academics/courses/ay01.html). Professors would like to be able to look at the content of other professor’s courses and allow students to see what a course’s content will be before enrolling.

7 / 21

Contact Information The second most requested data requirement was contact information, which is found in the “People” page of the ICS website (http://www.ics.uci.edu/people/index.html). An example of the contact information that most professors are interested is shown in Figure 3, which includes email addresses, phone numbers, office numbers, and links to professor home pages. All interviewees expressed that this page provides them with all the required contact information. Professors not only used faculty contact information; staff, graduate students, and researcher contact information was also very useful. One professor mentioned that a distinction between Master and PHD students would be nice. However, another professor indicated that all graduate students were equal and distinctions were not necessary nor should they be encouraged. As in all data gathering studies, each user has their own beliefs and this requirement would need to be further evaluated before a solid recommendation could be made. Perhaps an intermediary solution would be to link to all graduate students, but indicate what degree they are pursuing along with contact information. This would keep all the graduate students together, but satisfy the one professor that needs to know what degree a student is pursuing.

Figure 3: Faculty Contact Information

(http://www.ics.uci.edu/people/faculty.html)

Faculty Intranet Almost every participant (four of six) brought up the faculty intranet as a means of getting important information. Since the professor user group has specific user needs that do not apply to the outside world, the faculty intranet is a means of distributing such information. Currently professors access the intranet by going to the “Administration” website (http://www.ics.uci.edu/administration/index.html) and using the link in the left navigation pane. Since this is only accessible to the faculty some of the data items we recommend throughout this paper may already be provided through this means. Therefore, developers of the ICS website need to be conscientious of what data is provided internally and what should be provided externally in order to prevent overlap. From our interviews, we gathered that professors could get recruitment information, research funding and find out about other issues under discussion by using the intranet.

8 / 21

In analyzing the interview data, it was interesting to note that the faculty intranet is mostly accessed by professors, who do research, teach, and perform administrative tasks, whereas lectures did not consider the intranet related to them. As one interviewee stated, “I am a lecturer, I don’t do research. To me, the intranet is about research issues like funding, which has nothing to be with my teaching.”

Policies and Procedures Another important use of the ICS website is to disseminate information on policies and procedures pertaining to the department. The professor user group mentioned these in the context of teaching classes and in the context of performing administrative department duties. Professors that teach classes utilize the ICS website by providing links on their own course home pages to course prerequisites and academic dishonesty policies. They also use the ICS website to find deadlines for grade submission, for add/drop cards, etc. Much like course information, these policies are buried under student specific sections of the website and not easy for professors to find. Furthermore, once found (http://www.ics.uci.edu/academics/policies/index.html), the policy page does not contain all the information that a professor would find useful (such as the deadline for grade submission). The other use for policies and procedures pertained to the administrative responsibilities held by some of the professors. Department policies and graduation paths were important to professors whose duty is to oversee the their direction or answer questions of students.

Administration and Support One faculty member indicated that the responsibilities of the supporting staff members were not clear and suggested that staff contact information should include a brief description of their responsibilities. This requirement was elicited based on a professor’s experience trying to order textbooks for a course he was teaching and contacted the wrong person. This delayed getting his textbook for class on time and therefore negatively influenced class progress. Another example of needing support related information came from an example of not knowing where to report a printing problem. From the user experience it was not clear who should be contacted. From our analysis, this could be due to a few observations of the web site. First, computing support personnel are not clearly marked as such. This reiterates that listing each staff member’s responsibilities would very useful. Another reason reporting computing problems may be difficult is due to the different look and feel that most of the computing support pages show up in. This of course is speculation based on HCI principles of consistency. The last data requirement drawn out of this categorization was office hours for important ICS functional units such as the Distribution Center and Student Affair office.

Faculty Profile Another data requirement requested was to add a profile of each professor to the faculty listing. This would be a short description of what the professors research interests are, areas of expertise, and classes taught. This would prevent a user from having to visit each of the professor’s websites and would consolidate the information in one place. The reason for such information

9 / 21

was to give the external world a look at all the great work that professors in the ICS department are involved with, and provide professors with visibility to potential consulting opportunities.

Data Accuracy The accuracy of data on any website is important to encourage visitors to continue visiting. In our findings, interviewees were concerned that the ICS website contained many instances of inaccurate or out of date information. One such example included using the faculty contact information, where some faculty members are no longer with the department. Another example given was that the calendar on the website did not “seem” to have all the event information that goes on in the department. The validity of this last statement was subjective as we as researchers do not know all the pertinent events that should have been listed. More importantly was the fact that the professors did not always trust the content because of experiencing inaccurate data elsewhere within the site. Figure 8 shows the ICS Calendar, and one of the most important department events, “Commencement”, is not shown on June 15th.

Figure 4: Calendar for June 2002

(http://www.ics.uci.edu/about/calendar/index.html)

10 / 21

Functional Requirements Functional requirements decide what the product should do. In the following subsections we provide categorized functions in the order we believe that they provide the most value to the professor group given their relative feasibility.

Search Function In order to make information on the ICS website findable, a search mechanism is a requested information requirement. This functionality would allow quicker and easier access to any information in the ICS domain, which could include student and faculty member web sites. This was evidenced in a statement by one professor who said, “ICS webpage should provide a search function within its own domain.” Almost every faculty member mentioned search, as they indicated their belief that most of the information they need from the website exists somewhere; it is just a matter of finding it. We were happy to learn that the search function will be included in an upcoming revision of the ICS website.

Automated Web Surveys/Questionnaires Another feasible request, which would require some functional development, was the ability for professors to create web surveys or questionnaires for their students to submit useful feedback to them. We thought that although this only came up in our last interview, many faculty members that do not have web-programming skills would benefit from a web tool that allows them to follow a process to setup their own on-line surveys. Professors could use this mechanism to solicit information such as a preferred time to hold office hours. Another example of a survey could be mid-quarter evaluations. An automated tool of this sort would be a service to the professors and something that could be used by other user profiles as well. One of the benefits of providing an automated generator would be that one could keep the forms standard and follow some guidelines.

Calendar and Scheduling When asked if the ICS website could provide help or aid them in their day-to-day operations, it was mentioned that they would like to be able to easily schedule meetings with other professors and easily look up other professor’s availability. One of the professors showed up a calendaring system called “Corporate Time”, which he indicated was purchased by either UCI or the ICS department. It seemed feasible to either incorporate links to this web-based application or to embed the system within the context of the ICS web pages’ look and feel. Further exploration of this requirement would be needed, but from the standpoint of our user base, a common scheduling tool provided in the departmental context could provide value add.

Prerequisite Checking The idea of allowing professors to check a student’s prerequisites on the ICS website was elicited in our initial in class meeting with Student Affairs personnel. The problem that this tool would be looking to resolve is the inefficiency of a professor contacting the Student Affairs office, and the office taking too long to get back to the professor with information on whether a class of students all have the appropriate prerequisites to take a class. One lecturer said if he

11 / 21

requested the Student Affair Office to check the prerequisite, it takes about three weeks to get a response (while the whole quarter is only ten weeks). Therefore in most cases professors ignore prerequisite requirements. From our standpoint this is the least feasible functional requirement because it probably would involve working with the registrar to provide internal tooling, and furthermore this type of information should only be available to professors. Therefore if such a tool was created it would not belong on the ICS website, but could potentially be placed on the faculty intranet.

User Requirements The user requirements capture the characteristics of the interview participants. Because the user group is faculty, the characteristics of the user group are expert, skillful, and knowledgeable of the ICS department. As stated in our introduction, the professors we interviewed ranged from 7 months to 27 years with the ICS department. From our analysis, those that had been with the department for less time seemed to use the website more frequently than those that had tenure for a long time. From this, we concluded that the ICS website is a great resource for new members of the ICS department and a key tool that should be used to keep these people informed. Another interesting observation was that the three user profiles or types (professors, lectures and professors with administrative duty) used the ICS website in different ways. Lectures tended to access the site in a focused manner. As a lecturer, involvement with research was not important, so his course information is the primary concern. Therefore links such as “About ICS”, “Student Resource” and “External Relations” had little meaning to them. On the other hand, professors with administrative duty access the website in with a variety of tasks in mind. These user requirements varied depending on their daily work and therefore they seemed interested in the content on most of the website areas.

Usability Requirements “Usability requirements capture the usability goals and associated measures for a particular product” (Preece, 208). Usability goals include the effectiveness, efficiency, utility, learnability, and memorabilty of (in this case) the ICS website. We found that the faculty members we interviewed were not completely satisfied with the overall usability of the website. The most frequently heard problem was that the “Academics” page (http://www.ics.uci.edu/academics/index.html) is "not structured properly.” One professor elaborated:

“[it is] very hard to find information. Information exists, but different ways to get them… Classes and (degree) requirements are different. Some information is about degree, some about the classes itself i.e. course requirements. We need to separate course information from degree information, [these are] two independent concepts.”

12 / 21

In this final section of data analysis we classify usability requirements into three classifications to improve usability, they include ways to Improve Navigation Structure, retain a Consistent Look and Feel, and to Provide Advance Information.

Improved Navigation Structure As mentioned in the section overview, several professors mentioned that the “Academic” navigation menu is confusing. From our observation, users could not remember how they had gotten to where they were within the site. One possible reason for this is the sites’ lack of consistent navigation. From the home page a user is provided with a navigation bar on the left, however once he/she has drilled into the site this navigation disappears and a new one shows up. Some of the professors we interviewed indicated that a navigational hierarchy could reduce the number of clicks to some of the important sub pages and increase their visibility. Empirical evidence also supports this idea that shallower websites have better usability than those that require a user to drill deep before getting information (Preece, 415). One professor mentioned that the navigation bar could contain submenus that one can mouse over to get deeper into the site. We believe that this type of navigation could promote the memorability of the site and resolve problems such as remembering how one got to a page that is four clicks deep. Another benefit of increasing the navigation breadth is that it allows users to find the information quicker, especially if they guess incorrectly on their first try. For example, one professor stated: “[it is an] Illogical sequence of steps to find the ‘Schedule of Instruction’ (which is located under ‘Course Information’). In our observation, the professor did not find it quickly because the Course Information page was under the “Graduate” or “Undergraduate” subsections of the site, of which he is neither. However, with a submenu that takes a user three links deep, course information could have shown up without ever having to look past the home page.

Consistent Look and Feel As stated in the previous section, the current ICS website does not retain a central navigation scheme that provides a consistent look and feel throughout it’s pages. Pop-up windows often confused users while pages that have not been updated to the latest look and feel appear out of place. The fact that the ICS website is basically a web portal into other University web sites does not lend itself easily to doing this, however, whenever possible ICS web pages should at least retain consistency.

Provide Advanced Information Providing advanced information is a good way to prevent unexpected errors in user behavior and expectations. One are of the ICS website that was discussed by several professors was the home page. The major disappointment in this page is that the primary links are not well understood (“About ICS”, “Academics”, “Research”, “Student Resources”, etc.) and do not provide users with enough information about the underlying structure of each section. Another area in which advance information would be nice is when a link is going to pop-up an entirely new browser. At least two professors mentioned that they did not like this and it was unexpected. If advance information, such as an icon or text indicating you were leaving your current browser and opening an external web page could have at least mitigated this frustration.

13 / 21

Conclusion

The most challenging parts of our qualitative research were scheduling interviews and analyzing the data we collected. Because our user group is an extremely busy group of people, we used a couple techniques for setting up interviews, including sending personalized (not to a group) emails and dropping by offices in person. Both methods were successful in finding reputable and representative individuals from our user base of professors. From the data we collected, we found that analyzing the data in terms of requirement types provided us with mild overlap, but for the most part a solid foundation upon which we could organize our raw data into a comprehensible format. Our data analysis spreadsheet in the Appendix section gives an indication of how we were able to organize our data and the detailed summaries provide reference to more details of our findings. From our perspective, the important findings of this research effort are that the ICS website contains most of the valuable data needed by professors, as evidenced by our data requirements section. To improve upon the ability for professors to find information that is important to them, a search facility would be the highest priority functional requirement. From our user requirements it is evident that ICS website developers should keep relatively new ICS professors in mind as a frequent user of the website and should not necessarily expect long time ICS professors to frequent the site unless they hold an administrative position within the department that warrants more usage. Last, and perhaps more important than discovering users’ needs on the web site, developers should consider conducting an in-depth usability study of the website. From the observation part of our semi-structured interview we ran into more usability issues than data or information needs. In fact, this study provides developers with ample information to set up task flows and scenarios that test users of the website could be observed doing. We believe that this would lead to more valuable usability information than what was exposed in our interviews and analysis.

References Preece, Jennifer. Interaction Design: beyond human-computer interaction., John Wiley & Sons,

Inc., 2002.

14 / 21

Appendix

Interview Questions

1. Can you give us some background on what research you are involved with, classes you teach, etc?

2. How long have you been in ICS?

3. How often do you use the ICS web site.

4. What information do you look for on the web site?

5. What type of information do you think is missing?

6. Is there anything that the ICS web site could do/provide that would aid you in your everyday work?

7. Let’s take a look at the current ICS web site. [Exploratory Observation – Contextual Inquiries]

a. Can you show us some of the tasks you perform while using the web site. (get somebody’s email address, etc.)

b. What would you like to be able to do?

Interview Summaries

Interview 1 Uses ICS web site once a day, 7 months w/ ICS Typically usage:

• People and contact information (email & phone) • Home pages • Calendars • Classes • Schedule of classes • Deadline for submitting grades, giving finals, drop/add card (Scheduling information)

policies • Ex: Student affair office hour • Textbook order: staff page with not clear what the staff member responsibility

What’s Missing

15 / 21

• Easy method of finding people information (faculty, stuff student) • Academics section is confusing

o Can’t find who teaches 184 next quarter o Prerequisites o Enrollment restrictions (Very hard to find this kind of information, differcent

ways to get, overlap, not structured propoly, There are different ways, a lot of overlap. Information exists but structure is not good

o Support group page does not get updated often enough � Example: couldn’t find who to report printing problem to.

• Looking to order text books. Staff responsibilities are not clear. Maybe list what they do so the right person can be contacted.

• Student affair office hour • Timeline of submission • A distinction between MS or Phd students.

Helping Everyday work

• Most information is available, just not well structured • Search button would be useful

What kind of scheduling information?

• Office hours of student affairs office. • Dates, when drop/add cards are due.

Observation

• Goes to people, looks for telephone number of a faculty member. • In the people>student page, Distinguish between Master’s and PHD students.

o Uses http://cs.stanford.edu as an example • Go to Academics >> confused, wants information on ICSxxx, don’t know why hyperlink

to click. He needs prereqs, etc. • Classes and requirements are different. Some information is about degree, some about

the classes itself i.e. course requirements. Program information, etc is mixed in. Separate course information from degree information. Two independent concepts.

• Looking at the Calendar information. Not complete, never used. Pretty sure there were more events than listed. (out of date) --- not useful to him

o For faculty members, they care about their teaching, group meetings and weekly commitments. Seminars/speakers; usually these are via email. The calendar doesn’t necessarily need to be in the calendar look and feel.

o Corporate time, web based calendar

Would you like to be able to check if a student has met the appropriate prerequisites for a class? • Not quite interested because although there are prereqs, it is hard to enforce them. With

100 students, there is no way to go through all of them. It is the student’s business. Anything else:

• Two main suggestions:

16 / 21

o Restructure academics section � Mixing course information with degree requirements is one of the

problems. o Provide Search Functionality. o Schedule of classes with link to home course page.

From my prospective, I just want to get the info very quickly following certain links

Interview 2 13 years w/ ICS ICS web site is home page. Doesn’t mean he uses it though Typical usage:

• Refreshes memory on where he needs to go to teach (classroom) • Uses as a portal to the EEE web site. • Searching for phone numbers, information in general

Missing from site:

• Labeling is misleading. (???) o Example, to get to registrar’s office, click on Academic

• Profile of the professors, what do the professors do; oriented to the external world. (Instead of visiting each professor’s web page). He thinks that there was an attempt to do this (business office), but he failed to return an updated version of the home page they requested because he though he already had one. He is not looking for a whole page, (just an abstract with keywords and something the professor can update for themselves). Sending it to somebody else who puts it on the web page does not work. Interests, titles, what the professor can do. Gives the professor consulting opportunities. Gives professors and school visibility.

• Own Homepage-teach research student can find there

No observation, no pc setup in his office. Check mail

Distinguish between Master’s and PHD? • No, graduate students are graduate students. He believes in equality.

“Use the web, not abuse it. The web is public and accessible by anyone on earth.” This is what the intranet is used for. Private information is kept here. “confidential, departmental information” Information needs to be balanced between private and public domain.

17 / 21

Interview 3 Background:

• Has been with ICS department for 15 years How often access the website: at least daily to look at info What info to look for on the website: various, depends on daily job

• Faculty member websites to write letters of recommendation, or performance evaluation/ give a raise

• Course description to assign TAs and lecturers • Faculty Intranet:

o document under discussion by faculty o Faculty recruiting

• Guidelines: Student degree requirement, • External relationship, how many # of companies registered for a tutorial activity

What type of info think is missing:

• She knows the site pretty well, and thinks not so much is missing on the site • She has control of adding things considered missing from the site • Want to add a search function (in process of a shadow site)

What the site could do to aid your daily work:

• She wants to improve navigation structure: o On current homepage, it has just the top level, like “About ICS”, “Academics”…

� not save time � not sure if the searched info exists in the subpage:

o Suggest: mouse over/ pop submenu to provide more info o 3 navigation systems are confusing: left (“About ICS”, “Academics”…), top

(contact, calendar..), and Quick Navigation bar on the homepage • “Academics” subpage confusing

Observing using the site:

• Look at ICS tutorial session to give a speech at the tutorial • Suggest: the US news school ranking on the homepage links directly to the ranking page • Faculty intranet: Faculty recruiting, writing recruiting cases • “Academics” subpage: don’t remember which page she visited (structure not easy to

remember) o look at classes o Graduate Student: fellowship opportunity o Some info like “Course info: classes offered next year” placed under

“Academics” instead of “Student resources” o illogical sequence of steps to find “Schedule of Instruction” (which is located

under “Course Information”

18 / 21

Conclusion:

• nothing is missing • just how to find the info, ie. A better way of direct access to information • Need somekind of search engine

Interview 4 Background: no research, teaching lower level ICS 21, 22, 23 How long been with ICS: 2 years, and got under at ICS, got a degree at UCI How often use the site:

• Never: only about 5 times since the new version came alive, “it is not something I need a great deal.”

• he accesses his page everyday (which is a subpage of ICS website) • He thinks the new site is better than the old version, which has too many categories

(links) What info to look for on the site:

• Can find everything • Ignore the research area, like “Research” subpages • Use the “Academic” and “People” subpages

o Course schedule: but usually other faculty member emails him the schedule before the beginning of a quarter.

o the propose of knowing the schedule is to trade place with fellow faculty members.

• And he uses the UCI searchable schedule (http://webster.reg.uci.edu/perl/WebSoc) more than the one on ICS website

o Course description (http://www.editor.uci.edu/01-02/ics/ics.3.html) o Go to “undergrad degree requirement” page, when asked by someone o “People” to get contact phone # (but he uses a printed telephone number sheet

directly) • Tends to avoid checking students prerequest

o As he can not check it himself o Takes too long for others (maybe the student affairs office) to check

What info thinks is missing:

• He considers himself just a lecturer, not part of the committee (quite different from profs.) Just focus on classes he teaches

• Data not accurate: info not update as professors who already left still being introduced on “General Catalogue”

19 / 21

• No central place to look for all the rules and regulations (like graduation requirements), as a new prof., (but I found the policy page: http://www.ics.uci.edu/academics/policies/index.html)

o Because he has been with ICS long time, so knows the rules and regulations like sign drop, add cards

• He views ics website as a “publicly available website” for advertising (make an impression towards prospective students), while “faculty intranet” as a “inside site”

• Would like to have a way of checking student pre-requisite right a way for adding a student to class (currently, he ignored this process because take too long to verify)

Observe:

• Go to “general information” in the “academics” page • Degree requirement in the “academics” page • Go to “People” page: look up office, # (not often done) • New policies page: to get info like prerequest, to see how it affects his class • Course descriptions, a more detailed prescription

Use the old version of “Student Affairs “website more than the new version to look for contact phone # (disappoint him as only general contact # is listed, and can’t reach during after hrs

Interview 5 Background:

• Research: distributed computing • Course Taught: Operating System, Discrete Mathematics (undergraduate course) • 1 year as lecture + three and half years as graduate student w/ ICS

How often access the ICS website: everyday What info to look on the ICS website:

• Faculty contact information • Class Schedule

There is a link from ICS website to register office. She prefer the older version of ICS website)

• Job information She seek new position available for herself

• Building location information • Distribution Center Information (hr) • Check open time of distribution center information

What Kind of Information should be added: Research information Observation:

• Go to “faculty” in the “people” page, and look for faculty contact information

20 / 21

• Go to “Academic”, check course information • Use Searchable class schedule • Go to Research page. She doesn’t use it much. She used to go to faculty homepage to

look for research information

Interview 6 23 yrs w/ICS Uses web site frequently, here I believe he meant UCI website What info to look for on the website: • Mostly used faculty intranet • Class information (size, description, etc.) using UCI website • Calenders • Schedule of classes • Open hour for the Distribution Center • Provide link to policy (lab hr, university policy) from his course syllabus website. What’s Missing • Current draft of classes • A survey (for his students to enter what time his office hour should be) • Some kind of calender with links to files • Some way of finding a good time for setting up faculty meeting • Some way of checking who taught the previous pre-requisite class What the site could do to aid your daily work: • Could not think of anything Observation • Goes to Administration, goes into faculty intranet • Goes to Computing support

• Goes to Course descriptions, a more detailed prescription • Goes to Calender information • Goes to 2001-2002 schedule of information Anything else: • No different between old & new ics website • Some of links are deep and took some time to find • Feel that everything he needs is there

• Feel a little lost when goes to Computing support

21 / 21

Data Analysis Spreadsheet The data analysis spreadsheet can be found on the next page. It was an excel spreadsheet that we have also exported to pdf format for inclusion in this document.

Group Six Interview Summary

Functional Requirements Data Requirements Usability Requirements User Requirements

Professor1 For faculty members, they care about their teaching, group meetings and weekly commitments.

contact info. calendars, class schedule, policy (add, submit grade) Academics confusing As a professor, he cares about teaching, group meetings and weekly commitments (calendar).

Search button would be useful Support group page does not get updated often enough "not structured properly, a lot of overlap" Very hard to find this kind of information (prerequisite, who teach ICS 184 next quarter, enrollment restrictions). Information exists, but different ways to get them.

check prerequest Staff responsibilities are not clear Mixing course information with degree requirements is one of the problems

Student affair office hourdistinction between MS or PhD students

provide class instruction location want to give profs. and department more visibilityprofile of professors (updated by profs.) for external users

Some way of finding a good time for setting up faculty meeting faculty intranet Feel that everything he needs is thereA survey (for his students to enter what time his office hour should be class info (size, description, schedule))

Feel a little lost when goes to Computing supportSome kind of calendar with links to files calendars

Some way of checking who taught the previous pre-requisite classsupport group: distribution center hr

From his course syllabus website, provide a link to policy (lab hr, university policy)

search function faculty member websites (recommendation letter, raise) Navigation: pop up submenus As a chair, her info needs various depends on jobCourse description 3 navigation system confusing working on the website and get info out of it and into it are part of her job

faculty intranet: recruiting, faculty discussion Academic subpage confusing, don't remember where she visitedguidelines and policies (degree requirements) could not remember where she was at the site. external relationship: tutorial sessionICS ranking"course info" should be under "Student Resource" not "Academics"

prerequest checking can find everything, ignores the "research" page. Uses only "People" & "Academics" page

As a lecturer, his access of the site is very limited to the class he teaches. "people" "academics"

"people" contact info, Course schedule (to trade place) (uses UCI searchable schedule); Course description; Degree requirements;

not too many links on the homepage, does not care if he need to spent more time finding the info (better than the old version)

data not accurate/updated in "General Catalogue" central place for policy like: add, drop, submitting grades

faculty contact infoclass scheduleinter departmental job infobuilding /office locationsupport group: distribution center hr

Professor 6

Professor3

Professor 5

Professor2

Professor 4