dB-CMS design 0.1

Wireframes for Templates

The following wire-frames are intended to provide a guidance for preliminary design of the templates. They are not intended as final appearance. It is important to notice to this respect that each community within domusBITae will adapt the system to their specificity. For instance, the logo and main colours (usually related) are a major source or appearance for each specific community, therefore colours must be eligible. There can be an standard colour, width, etc. but specific values should be manageable. Within the development process the features concerning set-up parameters must be decided.

As result of reviewing the following wire-frames design, two remarks should be done:
  • The "contact info" appearing at the bottom left side of templates T2-T10 must be excluded. Only a permanent link at the foot-page  should contain a link to "contact us"
  • Many wire-frames appears as being in the 'resources' section. This has to be considered as an example. The templates are not linked to specific sections. As a result, the navigation box within section may adopt a slightly different layout, e.g. showing section name.

(T1) Home page

Concerning the main-section-bar (About us | Resources | etc): it should be cursor-sensitive for each section, unfolding a box containing the subsections for direct navigation. This feature must be present in all the other templates.

The news board should be automatically fed by the last announcements/news form the news section (each new constitutes a page in the news-section) using the title / first image (optional) and a short or larger (optional) amount of text from the coresponding new-page. The column for announcements might be divided in sections, automatically fed from the last added pages in calls or dB news.

(T2) Overview 

It correspond to the main page of a section. Intended for providing an overview of the section purpose (e.g., what are the main activities in which the community is involved). It also provides direct link to most relevant items (e.g., most active projects) with a brief description. 

(T3) Normal content

It correspond to a page for free content editing. The text should admit articulation and title formats may provide an automatic content table if desired. It also should admit a multi-column arrangement: 2, 3 columns; 2 columns among single column, right/left side-bars.

The arrows shown in the drop-down section menu should be mouse sensitive. By clicking on the arrow, it changes from a horizontal position, in which the articulation of the subsection is unfolded, to a vertical (downwards) position in which the articulation of the field is visible under the corresponding subsection. When entering in an specific subsection (not already unfolded, the menu should automatically unfold).

(T4) Large list of items with very short description 

For accessing to/describing a medium size set of items (pages, files or resources). The fields should be eligible after opening a new page with such a template and re-arrangeable. Some fields may contain links to pages, archives, etc.

(T5) List of items with brief description 

For accessing to/describing a medium-size set of items (pages, files, resources, etc.).

(T6) Short list of items with description

For accessing to/describing a short list of items
 (pages, files or resources, etc.).

(T7) Personal Page

When opening the page or as a set-up feature, the fields should be eligible since the data gathered (and relevant for each community regarding its members) might be different. An automatic generation of this pages is desirable from a database of members compiling all the visible information, as well as private information for not public purpose (which access might regulated via a directory regulated by the aforementioned federated identity manager).

(T8) Agenda

It should keep an agenda for different types of activities/groups, which should be marked, for instance, by means of a colour criteria as a superposition of different calenders. Its visibility should be user-eligible.

(T9) Application form 

The application form should be linked to either: (i) a database or (ii) sending a email. 

In the first case, if the database is already opened, an automatic Application form could be generated with regard to the type of each data field. The managing user may adapt the text and/or positions of the fields. When the user who fulfils the form press the submission button, the data automatically enters the database registering the data and time of submission. 

In the second case, instead of 'submission' button a 'send' button should appear. The default fields may be: Name, email (for response), Affiliation, Purpose of contact, Text. After pressing the send button, a email should be sent to an email address indicated when the form is created and editable by the content manager. 

After the correct action (database uploading or email sending) a confirmation should be shown (email confirmation optional).

(T10) Archive 

 It should be related to a database of files. The user will see what their privileges allows him according to the user type after identification. Public data will always visible. A mark should be used to let the user what type of data, regarding confidentiality, is handing. Four types of users should at least be considered, in decreasing grade of access: (i) Managers, (ii) Members, (iii) domusBITae users, (iv) public.

(T11) Distribution list archives

Here an example of a mailing list is shown. On the left hand, a navigation board should facilitate a thematic and chronological retrieval of the discussion archives (emails contents). Several thematic discussion could be opened in parallel, thus a database should enable to keep several discussion and the managing system should allow to open new thematic discussions.

(T12) Glossary

Concerning reading access: the article, entries, discussion and history should be openly visible by any user. However, the editing article is only accessible to the editing team and contributors. 

Concerning editing access: the article should only be accessible to the editorial team, the editing article also to contributors. The entries could be editable by any domusBITae member, as well as discussion. The history should be generated automatically with the changes introduced with in the voice domain.

(T13) Access to domusBITae element (dB)

No template is planned, since a direct link could be a mark of a more integrated system. Nevertheless the linking among domusBITae parts is intended to work through a federated identity manager. If a identified user from community A enters into a privative element of dB, she/he doesn't need to identify again. When entering the system of an eventual community B, the user may be accepted with particular privileges, which should be managed through the federated identity manager.