Human Interface (suggestions)

  • Volker Schmidt

    Volker Schmidt - 2005-05-04


    Starting with RefBase sometimes shows some difficulties by navigating to the surface. It would (IMHO) be better, if the Surface is devided by logical structures. For my Installation I made some small changes in 3 files: includes/, includes/ and css/style.css. I want to describe my changes:

    In I added a new tag <div id="pagehead"> just before the Table. At the end of this file  I replaced the <hr ..> by  </div><div id="main"> to mark the end of the header information and the begin of the main section.
    In I did similar things: I replaced the <hr ...> just before the table by </div><div id="pagefoot"> (this marks the end of the main section). And after the end of the table I placed a </div>.
    This are all changes on the Source. All other changes are done in the css/style.css:
    First adding 4 definitions:
    #pagehead  { background-color: #f5f5f5; position: static; z-index: 101; top: 0px; left: 0px; width: 100%; height: 120px; overflow: visible; visibility: visible }
    #pagefoot { background-color: #f5f5f5; position: static; z-index: 101; top: 0px; left: 0px; width: 100%; height: 60px; overflow: visible; visibility: visible }
    #pagehead table { position: absolute; top: -15px }
    #main  { position: static; z-index: 100; top: 0px; left: 0px; width: 100%; height: 100%; visibility: visible }

    After that I added a "margin: 0px" to the body-definition.
    My last change was to exchange the font-family in the p- and the td,th-definitions to a non serif version.

    This makes a small difference between the place where the user finds the basic information and his information.
    There is a small problem with the height-definition in #pagehead and #pagefoot: If the page iss too small, the information will move outside the coloured box. I didn't find a solution for this problem. Without this information the div has the size "0" and it is not possible to colour the background.


    • Matthias Steffens

      Hi Volker,

      thanks for your suggestions!

      I'm not sure what you mean by "the surface". Do you mean the top section of a page? I use the <page up> & <page down> keys on the keyboard to quickly jump to the top or bottom of a page. That works extremely well for me.

      Are you suggesting that the page header and footer will be always made visible on a search results screen? If so, how good would this work with older browsers and smaller screens? The headers & footers in refbase are already pretty large. On a 15" notebook screen they cover together half of the screen! In most scenarios I presume that the user is first interested in the search results, second in the header (to refine her search results). The footer may not be needed at all. IMHO it would be better to provide options for showing/hiding the header/footer on the fly (as is done in Print view).

      We try to provide as much backwards compatibility as we can. I.e., any interface enhancements should really work with older browsers or less capable (e.g. text-only) browsers as well or should at least not get in the way for people using them.

      But you're correct in that we should think about using more CSS options in general.


    • Volker Schmidt

      Volker Schmidt - 2005-05-04

      Yes, I see the problems today testing with Internet-Explorer ... It was not completely planned. In the moment I removed the fixed position in my version (it makes problems with internet-explorer and on small screens) but the colour is always there.
      The idee behind the User interface or surface is to show an optical grouping of functions but I think the div is not the best solution, cause one have to give the size (it i snot connected with the entrence). Maybe it is possible to connect it with paragraphs to give them an ID.
      In the moment the inclusion of the DIV-tag with IDs changes nothing on text-browsers. In this way "old fashioned" browser get the original design, only browsers which are capable of handling CSS show the contents in the new way. I placed an example at showing the (german) entrance page with the coloured header. It looks like the user can find the common functions more eazy with such a small help.


      • Richard Karnesky

        The shading does look nice, but I think the HR in the default skin provides good separation too.

        I would like to make refbase more skinnable as well.  See:
        for what I currently do.

    • Matthias Steffens

      Hi Volker,

      thanks for the picture, I see what you mean. When designing the refbase interface, a clear & unobtrusive layout was one of the main goals. Colors should only be used when they actually have a meaning.

      That said, I agree with you that it may be beneficial to separate functional parts from parts that display content (i.e. search results). While I'd still favour the current look & feel, we should definitely provide more hooks (by means of unique tag IDs) for people who want to alter the CSS files.

      I'll keep that in mind. Thanks again for your suggestions!

      Regards, Matthias

    • Volker Schmidt

      Volker Schmidt - 2005-05-07

      Wow! This looks really nice and modern. I didn't wanted to make much changes in the source (I don't know how to program PHP). I agree that a hr is a good separation, especcially with text browsers. For your design: did you make (big) changes in the sources or it is (nearly) pure css?

        Best regards, Volker

      • Richard Karnesky

        That is the Monobook skin from Mediawiki (which Wikipedia uses).  I basically replaced the refbase header and footer files with those used by mediawiki (which does use CSS quite heavily, but this wouldn't work by itself & I did completely rewrite the header & footer).  The only caveat was that the header needed information that refbase normally thinks is in the footer, so I had to rewrite all those function calls.

        Eventually, I'd like to replace the header & footer scripts with an actual skinning class, with functions for the header/footer, etc.  This way, function calls wouldn't need to be rewritten.  I also would like to have skins in a directory which would be able to override the default skin.  This would make per-user or per-site skins possible for a shared refbase.  It would also makeit easier for you or others to keep your custom skin when upgrading refbase.

        If only I had time to code more! (But when I do, MODS XML (and so bibtex/endnote/RIS through bibutils) comes first...)


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks