Notes from the meeting with VDIVDE in Berlin, Sep. 1, 2000.

  1. Web Design
    1. About the MagiCom system:
      1. Java client OK for basic use (except the editor)
      2. New Web interface will be better. Gives the possibility of preview. But for editing purposes, MagiCom will always use designated editors. They do not invent editors by themselves but use any given editor on the machine.

      3. GB has no influence on general layout (which is OK), but what are the actual possibilities for style? The current site is very simple in this respect.
      4. Everything, which is permitted by HTML and refers to URL's instead of File links. This is also true for JavaScript, CSS, and partly DHTML

        Uwe: Gerrit sends style sheet, which has to be implemented.

      5. How flexible are the possibilities to implement more complex and more fancy designs?
      6. Quite flexible (see 1.1.6).

      7. Can we expect any help from VDI for design issues?
      8. Yes! Depending of course on the manpower paid for by the project.

      9. Would it be ever possible to add an avatar?
      10. Can only be decided, if technical details known (which avatar, Platform, etc.). Cost still to be decided.

      11. Can we use style sheets for the text pages?
      12. Yes, template must be made appropriately.

      13. Can we have more design types for the text pages (probably yes)
      14. Yes, as many as needed. We have to agree on a naming system not to get confused too much.

      15. Can there be pages that does NOT show in the left menu bar?
      16. Yes. We have to open a new root instance, assign rights to it. Then it is up to the editor to link this instance to other or not. Will be displayed if someone knows the ID.

      17. can there be <next><previous> buttons besides the <top> link/button (to avoid to much scrolling)
      18. No problem if next/previous stay on the same level. Order numbers are used for deciding which is next/previous. Button going up or downs are also possible. Must be included in templates.

      19. Every text page should have (hidden) the responsible author and a date is it possible to automatically warn an editor when pages were unchanged for three months?
      20. This information can be stored in the database along with the content. With special templates we could give a list of pages which are outdated.

        No action of VDI/VDE-IT necessary before Sheffield meeting.

      21. Is it possible (allowed) to have more different editors for different subsections?
      22. Yes. The delegation of editor rights is done by VDI/VDE-IT. "Some" editors are ok. But if there are too many editors it is neither good for watching the rights assignment or for the site itself. Best solution seems to have only few editors.

        Uwe: Gerrits idea here is to editors for the "main" sections or "books" (see 3.1.7). I strongly made the point that is not good to have many more than approx. 5, he accepted. I think that this is ok. We agreed to wait for the Web interface before doing that.

    2. General design:
      1. missing logos
      2. VDI/VDE-IT has not received the logos yet.

        Uwe: Will be send by Gerrit and/or Koenraad.

      3. could we reduce the HLTCentral button to only the hight of the white Jewels Site bar? and extent the main menu bar to the left
      4. Uwe: It stays as it is for the moment. VDI/VDE-IT will ask professional designers

      5. line right of HLTCentral button
      6. Uwe: remove line.

      7. missing *buttons* for main choices / currently no precise fit of menu bar
      8. Uwe: see 3.1

      9. separate "recommendation" item and "learn about" (=promotion) item
      10. Uwe: see 3.1

      11. tools & materialS
      12. Uwe: append "s" at the end.

      13. missing *lines* between main option and submenu
      14. Uwe: see 3.1

      15. missing *buttons* for submenu (and subsub menu)
      16. Uwe: see 3.1

      17. current submenu not nicely designed and confusing
      18. Uwe: see 3.1

      19. gray text header better goes along whole screen
      20. in the recommendations section a subsubsub menu is probably needed, this will be come ver complex in the left menubar
      21. navigation map missing, how will it look like?
      22. navigation help should be sub-item under navigation map
      23. when will the full site search option be active, how will it look like?
      24. Currently a full text search is available over all text elements in MagiCom. Other types cannot be search as of today (for some there is a workaround). Staps is working on a generalisation.

        Full text search in the Courses database is also available and implemented.

      25. can (and should) we have a completely different starting page?
      26. Uwe: mail Gerrit how many nodes he will need, add the nodes and assign rights to them.

      27. about multilinguality! How could we implement that, if we offer pages in more than one language?
      28. Currently this is possible only with a workaround for a maximum of two languages. Basis is a special template. A general solution is planned, but we do not have a delivery date yet.

        Uwe: No clear decision at the moment. Gerrit thinks of having a starting page allowing selecting different languages. This can be done by introducing a new node (see 1.2.15) and then add pages as needed.

  2. Databases
    1. Sites&Courses:
      1. left menubar should be used with items: introduction (=default), browse sites (Missing), browse courses, add new data, help (?) or direct help wheree needed
      2. Navigation on the left side questionable, better seem "real" buttons on the bottom/top. If wanted, it will be done but we have to make the gafical buttons.

        Jürgen: Browse Institution à List of sites. Search Courses à Search page; Add Course à a) New for editors, b) go to Default (login) page. Have a special "Registration page" and remove it from the default page.

        Appears on every page.

      3. Browse (two pages, one for sites, one for courses)
      4. Implemented as navigation on the bottom and search mask.

        See 2.1.1

      5. help text for search
      6. Specify

        Wait for getting help text from Gerrit.

      7. header "Search the sites (cq courses) database"
      8. Done on the browse sites page.

      9. poor presentation of "select language"
      10. Done.

      11. "select site" does not work (will compare to Browse sites), "select city" does work
      12. Both work now, done.

      13. distinction between site = department, and city
      14. Jürgen: See 3.2.2

      15. reduce choices to: search + reset + all courses in browse,

      16. reduce choices to: search + all courses in search results

        Jürgen: Make navigation bar much simpler for the everyday user!

      17. link under title should go to local site (NOT to department site actually!) Confusion reported by Karel Oliva
      18. Jürgen: Click on course title à goes to the "local" course details. Remove the link on Sites. In Details make Organisation, Department, ... clickable.

      19. additional button should refer to VDI database presentation
      20. solved by 2.1.9

      21. site link should go to Department site
      22. solved by 2.1.9

      23. Registration / new user:

      24. - more explanatory text per field
        - is enough data required for the site description?
        - site vs department?
        - should we require links to compulsory topics?
        (welcome page for foreign students for instance)

        Discuss, get recommendations and texts.

        Jürgen: Implement "Additional Information" see 3.2.3

      25. New course: buttons: search + all courses
      26. Solved see above.

      27. Browse sites on the basis of a map of Europe / maps of EU countries
      28. Could be done. We need a map and a list of sites to prepare it.

        Wait till answer from Gerrit or Anders.

      29. Add new data

      30. more explanation on Registration
        registration now requires all <site> information.
        This information goes (?) to the site database, and is
        to every course unless specified otherwise (?)

        Look at current version.

        Solved with the modifications under 3.2.

    2. Tools&Materials:
    3. Jürgen: General redesign necessary, see 3.3. A prototype must be ready before Sheffield meeting.

      1. buttons: search + all tools (what is list?)
      2. introduction/browse/add/modify: options in left menu bar
      3. About user data input/modification: everyone can do this temporarily, final addition should get editors' permission
      4. Koenraad happy with fields display?
      5. search fields OK?
      6. when can Koenraad send data (in XML)?
  3. New Issues
    1. Web layout
      1. Blue letters do not have good contrast to the gray "jewels" letters.
      2. Uwe: Try to find better colors.

      3. Search à "search site" rename
      4. Uwe: please do this.

      5. Add "s" to tools& materials
      6. Uwe: correct spelling.

      7. New Templates, 3 levels left navigation, then to top navigation.
      8. Uwe: Details have to be discussed again via phone or mail with Gerrit. The idea is to have navigation on the left side for only three levels. Starting on level 4, keep the left navigation constant and have navigation on the top of the page, but only within this section and level. See Gerrit "geneolgy" pages, ask him for the URL, I lost the bookmark.

      9. No underlining on the left navigation bar, no italic, other color with good readability. Font ARIAL bold. User has to be much clearer, what are buttons which can pressed and what not.
      10. Uwe: First have always Arial maybe bold. No italics, no underlining. A special character link "*" or ">" could be displayed in front of the active line. This is only a first measure, we might have to change this to something you find in They seemed to like this kind of buttons but even these do not show the state. May be we have to ask Staps to come up with the graphical buttons as we have already discussed.

      11. Navigation help + navigation map shall be static, may be as pictures oriented at the bottom of the page. Search should be tightly coupled with navigation, it is not a content category.
      12. Uwe: Both navigation entries and possibly the search should be displayed in the left navigation under the dynamic navigation tree. They should appear on every page. As they are static, we could use graphics here. Decide what looks best.

      13. Horizontal bar (top) is analogous to books, the left bar related to chapters.
      14. Uwe: This should be a good strategy for navigation. Maybe we could even use in HLTCentral. The entries on top lead to different books. In order to show where we are, the currently pressed button must be highlighted in some way.

      15. Top level navigation has to change color (YELLOW is good against blue). Has to show were the user ist.
    2. CoursesDB
      1. Have 4 links.
      2. Jürgen: Default labels for all links (Institution, Department, Course, Other), which can be overridden.

      3. Rename "Site" to "Institution"
      4. Jürgen

      5. Make new "Additional Information" field in Courses (Accept HTML commands!!)
      6. Jürgen

      7. Have a function to "copy" records kind of "Save As..."
      8. Jürgen will devise a scheme to do this.

    3. Tools DB
    4. All tasks for Jürgen. Will start after his holiday and finished for Sheffield with a prototype containing example data. After Sheffield we will go live with it. Co-ordination is with Koenraad de Smedt (personal: In official pages use if an email is needed.

      1. Look into and implement all fields; Data entry is necessary; Look into CoursesDB and make Tools similar.
      2. General access, no login; have a separate ("secret") page for editor who has to approve all entries. Done by new/accept flag. Restrict access to this page. Better is logging in for editors only on this page and keep token acquired here. No full login as in Courses necessary.
      3. Let the user modify their data; maybe only after entering new information; restrict the navigation!
      4. This can be done only for a period they have not left the page. If they want to edit later, this will only be possible via editor.

      5. Have different versions of Tools by copying "old" information (see courses). Display only "latest version" of accepted Tools for everybody. Editor has to accept latest version, which then get displayed.
      6. (Remember to keep a link to the old version)

      7. Proposal for comments: users must be able to enter user comments. Comments must be signed. There will be no rating system. There will be no requirement to log in or register before accessing the database or giving comments. Display the comments along with the tool, Decide on displaying it directly or have links later.
      8. Currently no moderation on comments although editor can remove any comment from the database.
      9. Comments have to have email and name of the person entering the comment!
      10. Have "subsections" of tools data in order to get shorter pages (see Projects database).
      11. Look at "".

      12. Have a special layout for printing all informations in a nice way, keep different sections for display not too much on the screen; navigation buttons necessary.