LiquidPub base requirements

From LiquidPubWiki

Jump to: navigation, search

Contents

Introduction

Roles

Each LiquidPub users plays one (or more) roles when she interacts with the system. Depending on the roles played, each user has access to different kind of information and can use different tools to perform her tasks.

Users accessing the system could fall in two distinct categories: they are either registered users, or casual site visitors. Inside the registered user category, there is another distinction to be made between users with administrative rights (called administrators) and users which want to exploit the site as a tool for performing some tasks (actual users).

Casual visitors

Visitors have limited access to site's information content: however, they should be allowed to:

  1. Read the news directly from the site;
  2. Browse through site's statistics (page access, etc): note however that part of the statistic could be reserved for internal QA team use;
  3. See institutional information and sites policies and guidelines, along with help on topics;
  4. View all published information (papers, statistics, etc….)

As one could easily notice, casual visitors allowed activities are limited to read access to information which would be anyhow available to everyone.

Generic users

Registered users may perform every activity that an unregistered user could perform (that is, a registered user “specializes” further the role of the casual visitor). Each registered user, apart from the specific category (or categories) she belongs to, should be able to:

  1. Post messages on her own blog, or directly blog on published papers;
  2. Use the “social” features. Social features are a set of tools the system offers to make collaboration between system partners easier, like:
    1. The ability to share personal favorite document collections, and also to view other users collections;
    2. The ability to send private messages to other registered users;
    3. The capability of define a “friends list”, that is, to create a group of known registered users, which would have by default special rights (like, the ability to browse through each others published content, or to being notified if someone log in, or if publish something new, and so on).
  3. Access and edit her personal profile information;
  4. Access the Information Center and hence
    1. Subscribe to published content;
    2. View news/information;
  5. Search and discovery other's publications through the whole system's data content, and also through comments, notes, and every piece of published information available;
  6. Tag and comment contents;
  7. Create personal collections of SKOs, and store them on the system for future use (thus building her own private classification system);
  8. Create and share personal thematic calendars. In other words, calendars associated to particular concepts.
  9. Access the Performance Center, limited to public information;
  10. Access the Poll Center, and participate to public polls.

Jobs / People Selection (hiring managers)

Hiring managers perform the following activities by means of the system’s functions:

  1. Advertise interested users of existing job opportunities (hiring managers are given authorization to publish job advertisement on LiquidPub news system);
  2. Receive and collect applications for a specific job;
  3. Perform users evaluation, by exploiting performance center evaluation facilities;
  4. Read through job candidates CVs (which the system would let the hiring manager inspect upon owners authorization);
  5. Schedule job interviews with candidates, to finalize hiring process.

The Job Application Management Center or Hiring Center contains all the tools a manager is going to employ to complete the above listed tasks, except for candidates’ evaluation: the Performance Center comprises users evaluation oriented tools, and is therefore best suited for this kind of job.

Administrator

They do all the “behind the scenes” work, taking care of the site's “health status” by monitoring it, performing all the necessary support tasks and scrutinizing users behavior to prevent irresponsible and/or malevolent use of the system by anyone. Instead of having a single kind of administrator, able to (and authorized to) work on all aspects of site maintenance, there should be more types of site maintainers, each specialized in a particular administrative aspect:

  1. User managers;
  2. Forums, blogs, mailing lists, and other “social web” tools managers;
  3. Objects (SKOs, comments, notes, etc) version control repository managers;
  4. Objects access control managers;
  5. Forums and blogs moderators (take care of users messages being always compliant with posting guidelines);
  6. News managers: albeit the majority of news published are in fact automatically generated from the system not needing human assistance, since they stem from system-managed events like new papers published, conference scheduling, interesting blog’s post addition, etcetera, there could be all the same some interesting pieces of information which could pass unseen, especially when they are published outside the system, for example on another site. The task of news managers is to retrieve, catalogue and publish news from outside the system, and also to publish advices and notes about the system itself (e. g., system maintenance warnings).
  7. Mailing list managers, taking care of the message being sent through the public (and the restricted) mailing lists related to the various SKOs.

Requirements

LiquidPub will be comprised of various centers and modules, each one working (substantially) independently from the others, but sharing the same conceptual data model. Therefore, the requirements are here listed subdivided among the project's centers and modules.

Project Center

Project center would allow managing projects related to the scenarios covered by LiquidPub. By project we mean the context in which the SKOs are created and evolved. The fallowing operation should be provided:

  • Project management
  • Search and navigate

Information Center

Here information about a certain document (or documents collection) can be retrieved, thanks to the document’s search engine: each search run result could also be saved as a collection. In addition, news and information about current events could be retrieved, read and commented.

Search and Navigation

  1. Search features:
    1. Basic search: let the documents, reviews, and all information be searched by specifying a word list, just like Google or spotlight. Shows results grouped (e. g. in columns) by type of object (SKOs by authors, all SKOs, reviews, etc..). Rank results according to a special ranking algorithm (PubRank): otherwise, it’s possible to order the result using documents fields as ordering keys: for example, order by title, or by author’s surname, or by year of publication.
    2. Advanced search: allows specifying search parameters in a way similar to Google advanced search.
      1. Allow also specifying rank criteria (e. g. by posing constraints on PubRank variation).
      2. Allows also specifying whether the search is to be performed among all the documents or just inside the group of user's documents, user's related documents, user's preferred documents and so on. Search results (both basic and advanced) are under version control.
      3. Constraints on time or on the person having made changes on the documents may also be placed: this could be useful for, say, get only certain versions of some documents.
    3. Search results saving: each search result is in fact a special kind of collection, because it comprises a list of documents, which are ordered according to their relevance with the search’s query. Just like any other user custom-made collection, even search query results could be saved and shared among the other users.
  2. SKO navigation: this feature would permit to navigate the SKOs repository, by “jumping” from one SKO to the related ones, either by following the citation links, or by seeing other works from the same authors, or commented by the same people, or with analogous tags attached on them.

News center

  1. News fetching and viewing: news could be fetched from a dedicated page on the site, or automatically from a RSS feed. News still to be read are emphasized; the tool will keep track of who reads which news for purposes of user profiling and better targeting of news deliveries.
  2. News filtering: news is filtered according to criteria specified by the user. These criteria could be changed at any time by the user herself: it's also possible to define certain categories of news which should be seen by every user regardless of their preferences (let say, administrative ones, technical advices, and so on). Upon user's approval, the system could also provide a list of suggested news, based on user's interests and preferences, as automatically inferred by the system.
  3. News bookmarking and tagging: each user could bookmark a certain news, or add a comment on it, or add a new post in hers blog on it.

Hiring center

The main goal of the hiring center is to facilitate and automate, to the maximum reasonable extent, the process of finding and hiring some high level professional figures for research jobs. It shares some traits with conferences and journals management centers, because, just like for conferences and journals, it helps evaluators gathering together all the meaningful information about the candidate, and also provides indexes and indicators for judging her, the main difference being that conferences and journals are about authors works, whereas hiring is about authors themselves. In order to achieve this, the center permits the user to:

  1. Post news about job offerings on the system’s news center automatically, just like a new CFP for some conference;
  2. Receive all the applications in a centralized manner. Each application would bear information about the applicant and his “status” in the system. Since we suppose that every applicant is already a registered user, status information may encompass, aside from a standard CV and users ranking taken from the Performance center, users “social status”: that is, a kind of measure of involvement in the project (e. g.: if they already served as conference chairs, journal editors, if they posted some articles, or comments, if they wrote some reviews);
  3. Contact directly chosen candidate for scheduling job interviews;
  4. Access the performance center to perform job candidate evaluation.

At the end, the hiring manager would obtain a collection of candidates, each one associated with her evaluation information, plus a list of works she has already published on the system. The manager would be free to compare therefore the candidates according to system-provided metrics, or by inspecting directly user’s published works on the system itself.

Poll Center

A poll center would allow users to create, monitor and view results for a public poll about a chosen topic: although only registered users would access the poll (and the poll manager would possess the right to further restrict access to a certain poll by defining a poll access group), the system should allow also creating anonymous poll, where no one, neither poll manager, would be able to see poll’s takers true identity. Poll center managers take care of polls and surveys life cycle management. They do:

  1. Prepare a new survey by creating a new question list, and also selecting the target audience for it;
  2. Monitor the survey's carrying out phase to assure everything runs smoothly;
  3. Collect pool's results and perform statistical analysis on it;
  4. Prepare and publish result's reports on the site (as a new SKO, of course).

SurveyMonkey (http://www.surveymonkey.com/) gives a good idea about how the site should look and what kind of features a poll system should offer.

Administration Center

This is a special kind of center which allows special appointed user to perform maintenance and monitoring tasks, to ensure the systems performs always correctly and efficiently: in order to accomplish their duties, special powers are given them, namely unrestricted access to site’s content and the ability to modify it despite site’s access policies. To help administrator better focusing on their competence area and also prevent them to accidentally disturb other administrators work, administration sub-centers has been defined, each one regarding a certain administrative task.

  1. User administration tasks: show every registered user and its related profile. In fact, the only hidden data would be the user's password, so it would be useful to find a way to separate user's sensible data from the rest of the profile. Let the administrator do the usual work (disable, enable, remove, change user accounts and related profiles).
  2. Group administration: defining rules which applies on groups of users rather than on single ones is in many cases the best solution. This function also allows administering auto-generated groups (e. g.: each time an SKO is created a corresponding “editors”, and “viewers” groups are also created).
  3. Version system repository management: this interface allows the administrators to manage every object lying under version control, that is, SKOs, comments, notes, bookmarks, hyperlinks, news, search results, blog entries, tags, forum posts, calendar and mailing lists messages.
  4. Access control: this feature allows administrators to fine tune users (and groups) view/edit authorizations on system's objects. Access for non-registered users (that is, casual site visitors) could be managed here as well through the definition of special access rules.
  5. News control: since news comes mostly from the system automatic news services, which continuously scan the system for gathering interesting new information (such as changes made to papers or new comments added, which prompt in turn for sending notifications to registered users), news managers tasks will be restricted to collect, characterize and post news from external sources to the system. Also they would have to occasionally correct news categorization process errors: should the system fail in assigning each news to its correct category, the manager would have a chance to correct it before it’s posted.
  6. Surveys management and site's statistics management: this would be about analysis of the collected data for supporting QA for the project.
  7. General system configuration: main system controls, let the administrators check system health status by monitoring its components.

Generic site features

User / profile management

  1. User registration: a site visitor’s register by creating a new account on the system. At first the visitor must provide an account name, and then an authentication token (usually, username and password). The system should then check whether the user is an actual human being or a web “bot”. The user enters hers access credentials, and an email address. An email is sent to the user to verify and complete registration. After that, one or more roles have to be chosen among those offered by the system: this is an optional step, since some users may just be “observers”, who don’t contribute to the system but would nonetheless like to extract and collect information from it for their own reasons (e. g., research center administrators, european commission’s research evaluators): anyhow, more roles could also be assigned to the user afterwards. Then a profile is created and associated with the new user account. The profile includes personal information (which are mandatory only for certain roles (e. g., authors or publishers), but not for others roles, like the reader, who could provide just a nickname). Then the procedure should ask for user's preferences, which could be changed later: therefore, this part of the registration process could be skipped by the user. One could also upload oneself curriculum vitae, if her role permits that.
  2. User login: each user provides hers authentication token (usually, username and password). Services for recovering lost passwords would be provided, but the procedure must be highly secure, since user personal data contains sensitive information (the review they have done, etc…). The user could also indicate whether she should be kept logged in or not (i.e., whether cookies shall or shall not be used to keep track of her presence).
  3. Edit of user's preferences/personal info: upon login, a user could change its preferences, and personal information.
  4. User logout.

Since the roles defined for the system will likely change during its developing phase, but could also be modified later, after the system has been formally deployed and is operational, as new roles will appear in response to community's future needs and preferences, the system should be flexible enough to support dynamic role management, that is, allowing administrators to add, to edit and to remove roles and their association with resources and tools available on the system. This also implies that the following list is necessarily incomplete (and, as stated before, it's likely to ever be so) and naturally “work in progress”.

Community facilities

  1. Calendar sharing facility: it would permit every user to share their calendar with events, personal appointment, and etcetera. Should support the iCalendar standard for sharing the calendar among different applications.
  2. Forum: this is a standard web-community feature; it should allow the users to post messages which could be replied by other users, in order to build discussions or threads, it would have different access level, based on user's access credentials (administrator, moderator, common user), it should permit queries on the messages text, private messaging between the users, opinion pool making, and so on.
  3. Mailing list: apart from some general-purpose mailing lists (like, news about the project, latest SKOs added, and so on), each SKO should have an associated mailing list, for hosting SKO's collaborators, readers, bloggers discussions.

Calendar and events management

  1. Calendar facility: would permit the user to see its scheduled activities, plus other community related events and so on. Each group of related events will appear as a layer the user could turn on or off, thus making easier to avoid overlapping or bad planning.
  2. Activity planning: it should be possible to plan an activity by marking its start and end time directly on the calendar: this information could be shared among other users.
  3. Time annotations: scheduled activities, events, deadlines, even days, weeks or spans of time could be marked by a note, a comment or a tag. Following the above mentioned rules, this information is also to be versioned and shared upon user's authorization.

Integration with other social networks

  1. Single sign on among different web sites: by taking advantage of common standards like OpenID, the system would let one identify himself with the same access data for LiquidPub as well as for other web systems (like social web networks).
  2. “Find me elsewhere” service: users logged in the system will also be able to see a list of the other social web accounts they owns and access the sites pages by clicking on their names on the list from the LiquidPub pages.
  3. Component integration: it should be possible both to integrate widget/plugins coming from external services directly into LiquidPub pages, and to export LiquidPub functionalities so they can in turn be integrated into other's pages. Again, it's possible to utilize existing frameworks, like to Google's OpenSocial, to simplify the development process (or, at least, to get inspiration from).

Blogging and providing feedback

  1. Add entry to a personal blog on research arguments: the system provides every user a space for posting personal comments about research topics. It should be possible to make references to SKOs from a blog comment, and vice-versa, by means of hyperlinks. Blog entries are also under the versioning system control as SKOs.
  2. Adding a new comment: each SKOs and/or blog entry could be commented by the users.
  3. Edit (version) a comment: just like SKOs, comment could be edited and committed.
  4. Remove a comment.

Boomarks and tags

  1. Add a new bookmark: user could make a bookmark pointing to virtually everything in the system, SKOs, person, journal or collection. If the bookmark's target is under version control system, one could specify whether she is targeting a particular version/branch, the latest available version, and the latest “stable” one, or maybe every version available of the same document.
  2. Edit the bookmark: anyone with the rights to do so could modify any aspect of the bookmark.
  3. Delete the bookmark.
  4. Tagging an item: would let users mark an SKO, person, journal or collection with information about the user's opinion. This could be made either free-form (by merely entering a word list which seems to fit, or some commentary), either by using a fixed range of possibilities (e. g., a number from 0 to 5). Comments and tags are always public, but the authors have the right to withdraw them, or change them. As with the bookmarks, the user could choose if she wish to tag a particular version or every versions of the same document.

Quality Analysis Center

  1. Site survey: user are sometimes asked to answer questions about site the quality of the implementation of the various site's features, including look and feel and administrative aspects. These information are anonymously collected, but the system must enforce a fair procedure (that is, everyone does the survey at most once).
  2. Web site statistics: this feature would allow viewing site's related statistics, that is, information about the number of visitors, the pages most frequently viewed, visitor’s origin, and so on. This is a standard feature, commonly available on many web sites, and it’s usually handled by dedicated tools whose job consists in parsing web server logs, build statistics and prepare other web pages to display statistics reports.
  3. Surveys and statistics reports: each survey would have a report page upon completion. It would be possible to perform various kind of statistical analyses, thanks to system computed indicators (average, variation, and so on): also a facility for charts and diagrams production based on survey's data will be included. The same features, namely reports and diagram generation could also be exploited for graphically enhance web site statistics resulting from the activities described at the previous point.

Cross-scenario requirements

Creation Center

In the creation center users are allowed to perform creation and modification of SKOs, the liquid publications which evolves continuously as various users contribute to them. Also, WIP management tools permit anyone to manage their works while taking a look on deadlines and schedule activities.

SKO creation and modification

  1. SKO creation: a user, playing the author's role, creates a document either by creating it from scratch on the site itself, or by uploading some preexisting document in any format supported by the system. A third option is also to do a fork from an extant SKO, thus departing from its original developing line and creating a new one.
  2. SKO access rule definition: it's up to the authors to define whether and under which conditions the document should be visible and editable, and this fact will affect directly the extent of the collaborative part of the SKO development. Nonetheless, the system defines automatically the commit access of every “user class”, based upon the document's author preferences and upon common assumptions on how work on documents is supposed to be done.
  3. SKO collaborative editing: any authorized user could make changes to the document: changes magnitude and extension would be affected by editor's “user class” and by the original author editing preferences. Changes could then be committed to the SKO repository in the main document's trunk or, if it's worth it, a branch could be made. In case of conflicting modifications, the system provides support for handling the issue. With the same mechanism it should be possible to edit SKO's metadata.
  4. SKO downloading (i.e., checkout): any registered user could retrieve a copy of the document at any stage of development and choose to download it on her local computer.

Work In Progress management

  1. WIP management: displays a list of the works a user has to complete (e. g.: SKOs, reviews, presentations); it is worth to note that some kind of works will never be “completed”, in a certain sense. For each task, displays also the next deadline (if any), and also shows a list of “interested people” (observers, reviewers, simple curious, etcetera), so one would be able to inform them in case of unplanned delays, rescheduling and so on (assuming change notification system works correctly). Comments and reviews will have different levels of visibility, chosen according to the author/context.
  2. Gantt diagrams and other project management goodies: shows a list of currently ongoing activities (but also allows browsing through activities history for past ones), as Gantt diagrams, with timelines and sub-activities. Displays also list of people involved in each activity (particularly useful for PC chairs).

Feedback and monitoring

  1. Feedback management facility: many modules of LiquidPub allow users to add comments, notes and various sorts of additional information: when someone adds a comment to either one's work published on the system, or to commentaries/notes/etc one has previously added to someone else's work, the user is notified, and it could see the related comment(s), and post a response, if he wants to do so.
  2. Monitoring center: a user could register as “observer” of certain works/publications, and being thereby notified upon each modification made on the observed object and/or upon each comment/note/etc someone attach to it.

Life cycle management

See main article at Lifecycle Management

Retrieved from "http://www.liquidpub.org/mediawiki/index.php/LiquidPub_base_requirements"