Discussion, Bugs and Features for SimpleMente Theme

Features

Discussion

improved breadcrumb navigation

thanks a lot for the quick fix! would it be possible to avoid two line h1 on top completely, maybe by:

• only display the page title big, and the other breadcrumbs small, either on the side, or on top, or bottom?
• not display the "immutable page", or only display it in the alt text?

Hi Thurner!

• The breadcrumb is not html h1 heading. It is just normal text which is shown big and colorful at a prominent place. Turn css off or have a look at the screenshot above which shows the theme how it looks like without css (The hidden text "You are here" is h1).

• You can change the size of the breadcrumb, e.g. the link texts or non-link texts (like the ">" character, the text "immutable page" or "info") just by changing "#pagelocation" in the screen.css file. You can make the breadcrumb as a whole very small so that it fits in one line, provide a bottom border to separate it more clearly from content, do, whatever you like and what fits your needs best. It's just the normal css formatting stuff..

• I have put the breadcrumb at this place, because if a screenreader starts reading a page, it it important for a user to know, where here currently is, at which level he is, what he can do with a page (immutable or not) and if he is viewing a virutal metapage of the current page (info action). Moreover he needs a quick way to navigate through the page (either by hidden h1 headings or skip links). These two things - easy page navigation and information about current page and its state (immutablilty, metapage) must be right at the start of a page in my eyes.
• Immutability of a page has to be stated explicetly in the text, not in the alt text, so that it is clearly read to the blind. I don't like the way, Moin does it currently: Replacing the menu item "edit" by "immutable page". Menu items should be static in my eyes (therefore triggering an error message when trying to edit an immutable page) or inactivated (grayed out) but not replaced by some new text (Toggle functionalty of subscribing and quicklinking a page is an exception).
• You can turn off this behaviour by commenting out line 377,378 in simplemente.py (V1.0). However if you do this and use at the same time simplemente's way of an easy editbar customization there is no way for the user to know about the immutability of a page.

Cheers! -- OliverSiemoneit 2007-08-16 18:46:39

Notes about the improved breadcrumbs:

• Page status is an important information mainly done for blind users - then make it hidden for normal users
  • If you would have tested the theme, you might have noticed, that there is not way to inform the user about the immutability of a page. Standard editbar behaviout is overridden.
    • What do you mean by "there is no way to inform the user"? You can easily check if the user can write and display whatever information anywhere on the screen. How the standard edit bar is related to this?
      • If use customize the editbar with simplement, the default edit link is overridden. It does not change anymore to "immutable page" if you have not right to write the page. The user is only informed about the immutability by adding this information in the crumbs.
        • You can change it to "Edit (needs login)" or "Edit (needs permissions)", and add a title that explain why you can't edit the page. Both options do not change the item name in a significant way (I also not happy with changing the item to immutable page), and both inform about the status without clicking the link, which is nicer to the user.

          • No I don't like the idea to change a name of a menu item e.g. by adding extra information. This is totally uncommon. Just think of OpenOficce Word or so. There menu items which can't be used are simply grayed out, deactivated. Doing this in Moin (Render "Edit" as normal text not as a link)would be quite confusing. Leading it like it is and clicking on it, triggers than an error. But to inform the user in some ways, I thought, the best ways is to add this information right behind the page name in the crumbs.

• The "(Immutable page)" is bogus - the page is mutable, you simply don't have rights to edit it currently, maybe because you are not logged.
  • This is correct. However this is Moin standard. You should blame this to the Core Developement team that their diction is imprecise.

    • You can blame me for this; It was better than the previous behavior, I can't remember now what it was

• Page status in the bread-crumbs collapse with a page named "Page Name (Immutable)". Unlikely, but show why you should not mix different things in the title.
  • This example is theoretically possible but totally crackbrained..

    • And what about "FrontPage/Info for FrontPage"? is it the sub page "Info for FrontPage" or the virtual info page?

      • If it is clickable or read as link to the screenreader user, it is a subpage. Virtual pages a renderd black and not as links. You can't do backlink search on virtual pages.

      Lets say you improve the title, and instead of the duplication "FrontPage / Info for FrontPage", you will use streamlined "FrontPage / Info". This also works nicely for other virtual pages: "FrontPage / Backlinks" "FrontPage / Similar Pages" and so on. These nice names will collapse with real sub pages names.

      • Indeed, this would be better. The dublication is not nice, but I can live with that. Problem behind this: the name of a virtual page is set by each action itself with send_title. Thus it is out of control of the theme code. Reprocessing and changing the title of the virtual page would be difficult.
        • It is quite easy to to get the current action name, you can see how theme code does it currently for shouldShowEditbar and similar methods. I agree that this ugly, but nice title is very important.

          Just displaying the action name is not enough. Just think of search. The seach term is only stated in the page name (of the virtual page). Replacing this just by "search" wouldn't be good. I also don't now, which page names all the actions on ActionMarket set. Page name of an action is set by the respective action, which should convey some special meaning. There is now one-best-way in the theme code to process this page name nicely. Page name of an action is out of control of theme could. Changing the page name could be considered as an violation of the integritiy of an action.

• Add action result as "virtual sub page" - collapse with real page with the same name. The idea is great - but it should be implemented in the url space. Instead of "PageName?action=info", use "/info/PageName", and "info/PageName/SubPage". But this change cannot be done by a theme. A possible solution is to show always the page name, show the action name in the sub title, and use the page name as a link to return to the page. Currently the page name is used as a backlinks search, but this is unintuitive and confusing feature that should be killed anyway.

  • If you have "TestPage / Info on "TestPage" clicking on "TestPage" takes you back to TestPage. If you have "TestPage / SubPage " clicking on "SubPage" performs the normal backlink search. Clicking on "TestPage" takes you back there.

    • This inconsistent design. When you click on a page name - the same thing should happen - always. You don't want to surprise the user with "smart" unpredictable behaviors. I suggest that you always show the page, and move backlinks search elsewhere.
      • This is true. On the other hand - if I change this - a lot of people would complain here, that they are used to click on the page name to perform a backlink search. A solution that fits all needs of everybody, is impossible. I didn't want to go to far away from default Moin behaviour but improve in some parts. Above I have provided a new action backlink.py which allows to put backlink search in the editbar and thus in a more prominent place, which could also found and understood by wiki newbies.
        • You don't need to make everyone happy - just most of them. This is the time to kill the backlinks search in the title and use it for navigation. Showing the page is much more important and common than backlinks search. Count how many times in a day you so a backlinks search, and how many times you navigate to the page using the breadcrumbs.
          • Seldomley do I use backlink search. Often people complain, that the clicked on the page title to get a refresh but instead they got an hour lasting backlink search. Maybe it would be really better to turn this of an use for backlink search only the action (which could be put in the editbar) I have provided above.

• From design point of view - its a mess. Compare this with well designed interface. The title in this example is clear, simple, allow you to navigate back in the hierarchy, and looks great. It does not contain additional info and "virtual components". Put additional info out of the title.

  • I like the combination of virtual components and additional info in the crumbs

Questions:

• Lets say that a blind user read the half of the page, and forgot about the page immutability. Now he like to add a comment, how can he find that he can't edit the page?
  • Clicking on "edit" will trigger a normal error messasge. The blind user will find the error message easily since it is placed right at the beginning of the page and marked by a hidden h1 heading and/or easy to reach by skip links.
    • So you can drop the "(Immutable)" in the title, as the user will find this anyway when trying to edit - exactly like a regular user - both will have the same experience.
    • How the blind find the "edit" link?
      • Three possibilities:
        • By using the skiplink navigation at the top of the page to jump quickly to the editbar and then use "tab" (ie) to jump form link to link

        • To use the hidden heading h1 navigation to jump thourgh the page to the <h1>edit and actions menu</h1>. Then us "tab" ie to get the desired action

        • But best use accesskey support of SimpleMente. To avoid clashes in languages and with different assistive technologies SimpleMente has no global accesskeys. Accesskeys(Shortcuts) are definded by the users only, like they need them, like they want them, like they can remember them best. Therefore a shortcuts definition file needs to be uoploaded to the users homepage (in the longrun: should better move in userpreferences. But this is not theme code). Simplemente (i.e. some short javascript) augments every page with accesskey support now. I have changed ThemeBase in a way that you can now define accesskey for simply everything, the trail, navigation links, search field, edit, preview, save changes, go back one page (two, three) in the trail, go to the top of the page, to the bottom..

• There are case when you have static wiki pages, that only the admin can edit. There is no point in telling users that they are immutable, they may not even look like wiki pages. This is common issue on a site based on a wiki. How do you disable the "(Immutale)" addition in the title?

  • Simplemente is not meant as an CMS theme (like ModernCmsTheme). When using it in a normal wiki, it is important to tell the user, that this page is not writable for him.

    • You can easily add configuration that will allow using the theme for different kind of sites. At least make sure that you can override the part that adds the "(Immutable)" in a subclass without rewriting the whole method that creates the title. Best, make it configuration option, so you don't need to subclass the theme to change it.
    • Maybe having an option to disable "Immutable page" would make some people more happy. That shouldn't be that hard to implement.

• How do I add a "gui edit" link? I tried adding (u'Edit (gui)', u'edit&editor=gui'), to the simplemente_editbaritems array and found that the "&" and "=" get translated into html character codes. Is there a way to stop that? --counterpoke

  • This is currently not supported, since the gui-edit has to be considered as inaccessible. To get it work use  u'Edit (gui)', u'edit'), only and chance in wikiconfig.py default editor to gui and force also usage of gui there. Changing editors can nevertheless be done by the appropriate buttons in the editor window. -- OliverSiemoneit 2008-02-12 12:53:30

  • I really wanted two different links for edit (just like the modern theme). But thanks for responding back. --counterpoke
• The CSS specifies 'bitstream serif', where it should be 'bitstream vera serif' --counterpoke

Bugs

The MoinMoin release 1.6.1 raises an error like : Theme instance has no attribute 'linkSchemas' I changed around line 826 the following code (don't know if it's correct; but it works for me). -- MarcelHäfner 2008-02-04 10:55:10

FROM (old):
for scheme in self.linkSchemas:

TO (new):
for scheme in config.url_schemas:

Same thing happened to me in 1.6.2 and Marcel's solution worked OK... what's more, Marcel's change doesn't break 1.5.8 so maybe Eduardo would be nice enough to commit the change for us -- MarianoAbsatz 2008-03-29 20:03:47

The css for the new 1.6 'comment' class which supports inline comments like this seems to be missing which means that when I use comments, they just appear as plain text! Other than this (and liking an edit button at the top of my pages), this is a lovely theme and extremely well documented: well done! - Tushar. (..and forgot to mention that the 'comments' link which is in the edit bar in the modern theme seems to be missing altogether also)

InterWiki name

When using interwikiname and pages with subpages, instead of showing:

• InterWikiName: MainPage /SubPage

it shows

• MainPageInterWikiName: /SubPage

(that is the inter wiki name sticks to the right of the main page name)

Here's an example... the interwikiname is ClueLess, the page is VirtualMachines/KvmQemu:

workaround

I can remove the interwikiname altoghether by setting:

show_interwiki = 0

in the config file...

-- MarianoAbsatz 2008-10-29 20:47:27

Version 1.7

I made a small patch to use the theme on my moinmoin 1.7 rc3, see: simplemente.diff. -- MarcelHäfner 2008-06-16 18:57:20

Version 1.8

Ugly Fix for 1.8:

• With Version 1.8 you receive some errors because of the  self.cfg.hacks.get . Well I just removed this special IEX JavaScript "handling" and for my Linux with Firefox it works :-). Maybe somebody with a bit more knowledge could fix it right... here atleast the diff to the latest official version (for 1.6) simplemente-v1.8rc1.py.diff The problem with this theme is, that it is some kind of prototyp, a study into accessibility and how far you can go with that in a theme. I have tried out a new approach to have accesskeys in Moin (thus being able to work quickly with the keyboard only). However this approach needed overriding large parts of theme/_init_.py . This makes it very hard to maintain the theme from version to version. I have already done a feature request to move that crucial part into the standard distribution, see FeatureRequests/BasicAccesskeySupportInsteadOfBuiltInAccesskeys. However the core team is reluctant on that. -- OliverSiemoneit 2008-10-06 22:45:31

bug fix for AttributeError: 'list' object has no attribute 'render'

I was getting this error:

      /usr/share/moin/devwiki/data/plugin/theme/simplemente.py in msg (self=<wikiconfig.plugin.theme.simplemente.Theme instance at 0xa3bf2ac>, d={'available_actions': ['use self.request.availableActions(page)'], 'home_page': ('Self', u'xxx'), 'last_edit_info': {'editor': u'<span title="xxx">xxx</a></span>', 'time': '2008-12-10 09:23:12'}, 'logo_string': u'<img src="/cv_logo.png" alt="Clearvision Logo">', 'msg': [(<MoinMoin.widget.dialog.Status instance at 0xa3bf16c>, 'dialog')], 'navibar': ['use self.navibar(d)'], 'page': <MoinMoin.PageEditor.PageEditor object at 0xa3bf5cc>, 'page_find_page': 'FindPage', 'page_front_page': u'DevTeam', 'page_help_contents': 'HelpContents', ...})
         1. 949 else:
         2. 950 # msg is a widget
         3. 951 html = msg.render()
         4. 952
         5. 953 return u'<div id="message">\n<h1 class="screenreader_info">%s</h1>\n%s\n</div>\n' % (_('Message'), html)
          * html undefined
          * msg = [(<MoinMoin.widget.dialog.Status instance at 0xa3bf16c>, 'dialog')]
          * msg.render undefined

AttributeError

'list' object has no attribute 'render'

I fixed it by changing the msg() function in simplemente.py as follows (msg was being passed in as the list [(None, 'dialog')] for some reason:

    def msg(self, d):
        _ = self.request.getText
        msg = d['msg']
        if not msg:
            return u''

        if isinstance(msg, (str, unicode)):
            # Render simple strings with a close link
            close = d['page'].link_to(self.request, text=_('Clear message'))
            html = u'<p>%s</p>\n<div class="buttons">%s</div>\n' % (msg, close)
        else:
            try:                 # * FIX *
                # msg is a widget
                html = msg.render()
            except Exception, e: # * FIX *
                html = str(msg)  #  *FIX*

return u'<div id="message">\n<h1 class="screenreader_info">%s</h1>\n%s\n</div>\n' % (_('Message'), html)

Version 1.9

In v1.9 the theme didn't work at all untill I commented out this line:

pagename = request.normalizePagename(pagename)

Error was "AttributeError: 'AllContext' object has no attribute 'normalizePagename'"

In Google Chrome it was impossible to use links of Sidebar in some cases (example: http://www.wired-things.de/wiredwiki).

I replaced

float:left;

with

float:right;

in the Sidebar section of screen.css to fix it.

KirillMikhaylov

CategoryDiscussion