This is a summary of the functional requirements for the redesigned IS&T web site.

  • In general, the site will be more interactive and include more functionality (for filtering and sorting of certain information).
  • Breadcrumbs on each page. These are navigational breadcrumbs, showing the path taken by the user to get to a given page. Additionally, if a page is accessed directly from outside the IS&T web site, a pre-defined breadcrumb will show, based on the page's fixed position in the web site hierarchy.
  • Various pieces of pages will be expandable and collapsible.
  • Ability to maintain state for a user session. For example, if the user collapses a content box, the box will remain collapsed for subsequent visits to the page during the session.
  • Ability to customize the site in various ways. This requires user login and persistence of preferences and choices.
  • There must be page components with dynamic content (for example Systems Status, What's New). There will be various methods of getting this content to the screen (RSS etc.).
  • Some of this dynamic content must be context-sensitive. For example, relevant quick start classes. "What's new" or "spotlight" type areas could be populated via blog/RSS.
  • A "Top 5 Questions" section, which could be pulled from a stock answers system. Certain questions/answers could be marked to appear in this area and time-limited. Context-sensitive top 5 questions.
  • Ability to filter certain content by various criteria (e.g. software by platform, support-level etc). Ability to sort this data in different ways.
  • A Support Page is planned. Dynamic elements here are "ask a question" which will search the stock answers system, and "submit a question" to the Help Desk, which will feed into RT.
  • There was some discussion of tag clouds to identify hot support topics. These clouds may be filtered according to some separate choice of subject. We may want to have some way of marking topics so they have more weight in the tag cloud.
  • Simple poll on each page to ask if the page helped. Perhaps also a text box to capture more information. Other useful information to be captured would be what did a user search on to get to the page and/or what was the breadcrumb trail that got them here.
  • No labels

3 Comments

  1. Catherine T Iannuzzo

    I have a ton of questions associated with these requirements -- I still don't know enough about the site  to understand what the implications are for 1) what kind  web app is needed to deliver this functionality and 2.) what kind of content the web app is providing and what for. Here are some of my questions:

    This is a summary of the functional requirements for the redesigned IS&T web site.

    • In general, the site will be more interactive and include more functionality (for filtering and sorting of certain information).
      • so exactly what  information is filtered and sorted? in response to what user action does this happen? is it associated with searching? something else? are dynamic index pages being generated (and if so, in response to what criteria/state/attributes/etc), or is this a matter of dealing with result sets from queries?
    • Breadcrumbs on each page. These are navigational breadcrumbs, showing the path taken by the user to get to a given page. Additionally, if a page is accessed directly from outside the IS&T web site, a pre-defined breadcrumb will show, based on the page's fixed position in the web site hierarchy.
      • we will do whatever we are told to do, but I would strongly advocate that this violates rule #1 of user interface design, which is do not surprise the user. A feature that  behaves inconsistently is  often worse than no feature. The "breadcrumb" UI concept is most commonly understood by web users as being a drill down/up feature, not a "history" trail. And when it arbitrarily acts like one thing and then the other,  it's going to be even more confusing. What problem is trying to be solved? Why overload the taxonomy (which is what breadcrumbs normally represent) with whatever this other problem is?
    • Various pieces of pages will be expandable and collapsible.
      • What kind of pieces are expandable/collapsible? is it menus? if it is menus, can this be handled by javascript, or does it require server-side state management and business logic?
    • Ability to maintain state for a user session. For example, if the user collapses a content box, the box will remain collapsed for subsequent visits to the page during the session.
      • what is a "session" for this purpose? again, can this be handled by client-side javascript, or does it have to be managed on the server end?
    • Ability to customize the site in various ways. This requires user login and persistence of preferences and choices.
      • exactly what kind of customizations? what are the benefits to the user from logging in and setting these preferences? It takes extra effort to login, and people have to feel that there is a sufficient payoff for doing it (e.g. people feel fine logging in to HR account to adjust their personalized benefits package, but if they have to log in to see public info  like MIT vacation days, the login is a dis-incentive to spreading information widely)
    • There must be page components with dynamic content (for example Systems Status, What's New). There will be various methods of getting this content to the screen (RSS etc.).
      • exactly what are these dynamic pieces and how will these pieces be populated? are they on every page?
    • Some of this dynamic content must be context-sensitive. For example, relevant quick start classes. "What's new" or "spotlight" type areas could be populated via blog/RSS.
      • what is meant by "content-sensitive?" In response to exactly what context? 
      • There is a huge difference between populating a piece of content by a blog or an RSS feed. Where would the RSS feed(s) come from? Where does the blog authoring take place? is a blog part of the IS&T website? are we building a blog element, using an open source blog framework, taking feeds from external blogs, or what?
    • A "Top 5 Questions" section, which could be pulled from a stock answers system. Certain questions/answers could be marked to appear in this area and time-limited. Context-sensitive top 5 questions.
      • "context-sensitive" with regard to what context? what criteria?
    • Ability to filter certain content by various criteria (e.g. software by platform, support-level etc). Ability to sort this data in different ways.
      • exactly what content is filtered/sorted? (same as question above). How does the user interact with this context? is the result of a general search? of a query posed to a sub-system?
    • A Support Page is planned. Dynamic elements here are "ask a question" which will search the stock answers system, and "submit a question" to the Help Desk, which will feed into RT.
    • There was some discussion of tag clouds to identify hot support topics. These clouds may be filtered according to some separate choice of subject. We may want to have some way of marking topics so they have more weight in the tag cloud.
      • so what is a "support topic" (or taggable entity)? who does the tagging? how do they do it? how does the end user interact with these tags?
    • Simple poll on each page to ask if the page helped. Perhaps also a text box to capture more information. Other useful information to be captured would be what did a user search on to get to the page and/or what was the breadcrumb trail that got them here.
      • It seems that there is an implicit understanding of what the user is doing that leads to this poll and the information capture, but I am not clear what it is. Does the front page have a poll? any random page that the user clicks or gets to because someone gave them a link? polls on pages about organizational teams?

    What would help us a lot would be to understand what is probably obvious to everyone except us developers. What are we trying to accomplish with this website? It seem that it is more than one thing, and clearly defining the objectives would be very helpful to us, since each goal may have a different technical solution. Some objectives that I could imagine are:

    • provide "user manual" type of information on how to do IS&T related things at MIT (e.g. use email, set up a new computer, etc)
    • describe the organization itself, its departments and their functions, major programs, etc.
    • provide a gateway to services (which are currently not actually hosted at web.mit.edu/ist), such as mailing list requests, download a certificate, etc.
    • provide notifications to the community, including status (e.g. 3DOWN), security advisories, service alerts, and marketing press release type of announcements of new products, programs, services, etc.
    • be a tech support gateway, including:
      • a knowledge base. The value of a knowledge base is in the usefulness of its taxonomy for browsing, as well as its searching ability.
      • an on-line help desk (IM click-tc-chat, a forum/bulletin board, input to an RT, etc)

     All of these are different types of functionality, would involve different kinds of content, different solutions for delivery as a web app. Would the site architecture (which we have not yet seen) make these different goals clear to us?

  2. Catherine T Iannuzzo

    Distilling my previous comments down to the real issue, I come up with a request for context -- what is the set of business requirements that are driving the technical requirements? is this available in some other docs? An example of what I mean by business requirements is below (I totally made these up, but I think they might resemble existing business requirements for the site):

     
    GOAL: provide a tech support knowledge base that is easy to use, perceived by the user as highly effective, and reduces help desk load.
    FEATURES should include:

    • index page about the knowledge base
    • ability to browse the knowledge base along several taxonomic axes - e.g. by operating system (like "windows" or "linux"), by component  (like "email" or "messaging"), by subject area (like "security"), etc. -- with any particular piece of information belonging to more than one taxonomic branch (like "email" and "linux"). Specifying the taxonomy is crucial to its success.
    • ability to query the knowledge base, using both easy keywords as well as more advanced criteria that can filter results and sort by relevancy or other grouping TBS; ability to save queries and re-run them easily
    • ability to rank the effectiveness of any knowledge base article, and for the cumulative rank of that page to be displayed in query results or used as a sorting criteria. Steps should be taken to prevent spamming of articles with false rankings.
    • ability to parse a English text question like "How do I get my email in Outlook" and search the knowledge base
    • ability for user to submit question to the help desk and create an  RT ticket

    GOAL: provide information about IS&T, its departments, and programs in order to facilitate transparency and communications with the MIT community.
    FEATURES include:

    • standard index page
    • organizational map, with ability to click on map items to bring up team pages
    • team pages that are easily edited by the teams themselves, in order to encourage them to be kept up to date
    • a "key initiatives" section with information about projects that we want to make more visible to the outside community. TBS: how often should they be updated?
    • a "what's new" section for announcements about the organization; this section should have all past announcements available in reverse timestamp order (newest first), but only the most recent should be displayed on the first page of this section, the rest would be available in a paged archive similar to a blog
    • links to blogs of key contributors within IS&T (TBD: find a few people who can write and generate some excitement about IS&T initiatives, architectural thinking, or technological roadmaps. Need to be careful about distinctions between personal views and views of the organization, need some policies for bloggers)

    GOAL: reach out quickly to the community with security advisories and system alerts, and provide on-going transparency into operations status
    FEATURES:

    • a prominent "news alert" type box on the main index page of the site that is populated in reverse time stamp order  with advisories from the security advisory system , system alerts, and status from 3DOWN. Links from entries in this box to more detailed information, where users may subscribe to email notifications.

    GOAL: provide marketing outreach about products, programs, and services; change content frequently enough to make it interesting

    GOAL: cross-sell services in response to patterns of user inquiry

    ETC.

  3. Stephen Turner

    Agreed - I think clearly stated business goals and requirements will benfit everyone involved in the project.

    Also - based on the current wireframes and designs from Tank, I have begun a more detailed analysis of the composure of the web site/web app, identifying the subsystems, the pages that these subsystems affect, and listing questions and unknowns.

    Steve