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:
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.
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.
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).
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.
For accessing to/describing a short list of items
(pages, files or resources, etc.).
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).
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.
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).
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.
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.