Contact
E-Mail: <oliver DOT siemoneit AT philo DOT uni-stuttgart DOT de>
Me and Moin
I'm running a small intranet wiki for a working group of the VDI, the Association of German Engineers. The working group is called "Technology and Society". Currently we are focusing topics like RFID, pervasive computing and context-aware applications and their effects on humans and society in general.
Since I'm not a real programmer, but "just" a programming philosopher, I have to contribute to Moin on a more conceptual level:
Currently, I'm running together with some colleagues of the computer science department a master thesis on wikis and accessibility. Goal of this master thesis is to give a rough overview on the state of the art on accessible webdesign, systematically explore potential barriers in wikiwebs for different handicaps and develop basics concepts to overcome these barriers. In the next few months, I will add some results (and own coding stuff) on AccessibleMoin to push the discussion on this a little bit further. See also ImprovingAccessibilityOfWikis for some more theoretical work on that.
My colleague DanielaNicklas has run a master thesis on ContextWikis a few years ago (see DanielaNicklas/KontextWiki). ContextWikis or GeoWikis are an extension of the wiki concept into the geographical realm: small handheld devices, which are equipped with WLAN and GPS allow to virtually pin certain wikipages to specific locations, e.g. your wikihomepage to your office door. If someone wants to visit you in your office and your are not there, one could see your homepage automatically on his device, read your message, that you are not there and maybe leave some information to you on your homepage. We have implemented that with the software we developp at your center of excellence (http://www.nexus.uni-stuttgart.de) and Moin.
This brought me up to the idea to have also some MobileMoin.
Own code contributions:
AccessibleMoin has a lot of stuff from me for wiki accessibility (page needs refactoring).
Small modification of the ImageLink macro, see MacroMarket image macro for that. This macro, which allows to resize pictures and provide an alt-text for them is needed for accessible wikis, since all pictures should have an alt-tag so screen readers could tell it to the users, what others could see. And it is not a big help to have an alt-tag with the filename "pic1.png" like in TWiki and call themself accessible! Rather, the alt-tag should be a short explanation of the picture. This means in the end: wiki users should use the image macro to display an image and not the attachment macro. You see: accessibility concerns different levels form pure coding and patching of the wiki-engine up to coding guidelines for the users and their enforcement.
Patch for FeatureRequests/MakeInvitations
Patch for FeatureRequests/PossibilityToSetQuicklinksAndSubscriptionsOnAccountCreation
Patch to ameliorate printing on up-to-date-browsers which don't need to call "?action=print" anymore (only needed for archaic users and browsers): MoinMoinBugs/ToggleLineNumbersInPrintPreview
- and others..
Messages to Me
You can leave messages to me here..
Hi Oliver, seems files (data) need always a description for accessibility. May be we should enter a default description (comment) at time of upload. So we could use that for AttachList and others which have no inputs too. Perhaps in a further version the file object could be the file data itselfs and the description. What do you think on that? -- ReimarBauer 2007-04-06 20:49:46
Hi Reimar! Yes, Nico - our student who is working on AccessibleMoin - has already suggested that. He wanted to add a new field in the AttachFile form where you have to specify an alt or description text on upload. I think this is a good idea. Question is: where to save this extra information now? In a plain text file in the attachment dir? Should we make a difference according to the mimetype? How could this be integratd in future to one embracing 'attached object'? This needs some further thinking.. -- OliverSiemoneit 2007-04-06 21:57:49
Without the changes in the storage engine it's not easy to solve that because moving, deleting or renaming should go well too. I would prefer a description file for each attachment file yet with some more optional info as only the alt text. e.g. viewable size, who has uploaded, a longer text about. The files should be hidden for the attachment code so they have to start with a dot. All attachment handling routines have to try if a corresponding file exists and have to do the same with that as with the attachment. -- ReimarBauer 2007-04-07 07:17:36 We should discuss items and what needed for attachments at StorageRefactoring/ItemHierarchy -- ReimarBauer 2007-04-07 08:53:20
This sounds perfect to me, so there is no need to discuss this from my side. For AccessilbeMoin I think we will start having some extra info file as you suggested, e.g. ".filename_type' or so..
Problem also: there is no 'best' alt text possible, i.e. an alt texts that fits all cases. An alt text depends on the context always. Take an image of a wonderful beach in the Caribian see. One alt text could be "An image showing a wonderful beach of an Caribian island" Another one could be "An image showing the boring lonelyness and that nobody wants to go there. No discos. No girls. No beer. So what do you want there?". Another one: "An image showing typical tropical cumulus clouds which are going to build up to a heavy thunderstorm in the evening".
I started to discuss improvements on PIL (discussion thread). May be add also your wishes. -- ReimarBauer 2008-12-18 13:59:23
Hi! I'm the student working on RealTimeEditing2009. I'm trying to integrate your request about syntax highlighting to my project. I have done a small comparison of available editors with syntax highlighting available (see project's page). I'm leaning towards EditArea, mainly because it doesn't use an iframe, which would make things a bit more difficult. Do you have any comments, any other editor I'm missing? Thanks. -- AlexandreMartani 2009-07-30 04:29:52
It is a long time ago, when I had a look at different solutions for syntax highlighting. At this time EditArea seemed to me one of the best solutions. It also implements other features which are often requested such as search and replace and so on. As I have seen on the homepage, EditArea is still maintained. Last release is April this year. So it might be a good choice. However I havn't looked at the code yet. ThomasWaldmann and ReimarBauer are excellent in that and can judge that much better than me. I'm really looking forward to get EditArea and RealtimeEditing implemeneted. That's great! However, from an accessibility point of view, there is, in my eyes, no way to drop the old simple text edit box with edit conflict warnings. This could mean in the end, that Moin has 3 different editors implemented: the normal one with the text box (for the purists and users with special needs such as the blind), the EditArea (for users without special needs looking for a comfortabel way of editing) and the GUI (for those who can use Word only and even sending an email is too hard a job). -- OliverSiemoneit 2009-07-30 17:34:51
Hello Oliver, I've ported the abbr.py parser to MoinMoin 1.9 with some modifications: https://github.com/artyom-poptsov/moinmoin-abbr-parser
I know you're one of the developers of abbr.py 1.0. So could you please answer two questions:
Could you please clarify whether I may use GNU GPLv2+ for the parser? I'm asking because the license for abbr.py 1.0 was specified just as GNU GPL -- that is, without explicit declaration what version of the license has to be used. I've asked JohannesBerg and he told me that "Moin itself is GPLv2+, so he'd consider his code hooking in the same". Do you agree to use GNU GPLv2+ for the parser?
I'd like to place the new version of the parser on ParserMarket/Abbreviation as the version 2.0. I've asked JohannesBerg this question too and he said that I may do that. Do you have any objections or comments on this?
Thanks. -- ArtyomPoptsov 2013-11-07 19:15:48
This is great