Request For Comments: layout, accesskey attribute, doc

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
6/16/2006 3:18:18 AM
Gravatar
Total Posts 23

Request For Comments: layout, accesskey attribute, doc

I have a few proposals and would like to know what you think about it:

1. The "Welcome User Name!" should be replaced by "Logged in as: User Name" because it sounds/is more 
professional. You have just to remove the exclamation mark and the culture key translations could replace the 
rest.

2. What´s about a wiki-based documentation where at least the developers should get write permissions. A 
German OSS project dd-wrt.org have created a well documented OSS project in this way.

3. Every important button should get an "accesskey='Alt + Key'" attribute so the user have not to click on the 
button every time he make a change but just execute the appropriate shortcut.

4. The both img links at the bottom should be replaced by a variable copyright containing field. I think if 
people really like mp, they will put a text link to mojoportal.com which is also better suitable for the 
search engine crawlers.

5. For more Unix compatibility (just a remark for the future): Every file should contain an empty newline at 
the end. That´s a common convention for Unix configuration/src files. Users that work on the console and view 
the the file via "cat filename" miss the word wrap an the output looks unaesthetic.


Btw, anybody knows when the mono/xsp/mcs people will implement all .NET 2 features into mono/xsp/mcs?
6/16/2006 1:22:29 PM
Gravatar
Total Posts 18439

Re: Request For Comments: layout, accesskey attribute, doc

Hi Alexander,

1. agreed
2. if anyone wants to help with documentation I will be glad to give them edit ability on this site in the Documentation section. I don't really want any other site or wiki. I think it is best if users can find all the need right here. I think we can improve the documentation for sure but no reason we can't do it here on thi site.
3. agreed, I've been thinking about that also
4. well thats really a recommendation about the skin on this site, anyone using mojoPortal can do as they wish, personally I like the image and it seems many people don't mind having the image on their mojoPortal sites
5. I'll try to remember that and add lines where I don't see them

I'm not sure about how close they are getting with mono 2.0 stack, my last testing was several weeks back and mojo was still broken.
I'm almost done with the key 2.0 features that I want to use in mojoPortal and will get back to testing the 2.x mojoportal under mono after the 2.1 release. Still a lot of features I want to do in mojoPortal but the core 2.0 things like webparts, personalization, membership provider, roles provider, sitemap provider, etc are almost ready and will be the major milestones for 2.1.

I gather from the mail lists that they are making progress, I see patches coming in for System.Web related stuff, but after the 2.1 mojoportal release I will try to submit bugs for every broken thing I can find.

Cheers,

Joe
6/18/2006 3:07:37 AM
Gravatar
Total Posts 23

Re: Request For Comments: layout, accesskey attribute, doc

Hi Joe,

2. I'm also of your opinion and I just wanted to extend *this* page by a wiki functionality for doc sites. 
So every user or at least devs could alter doc sites.
6/18/2006 3:34:39 AM
Gravatar
Total Posts 18439

Re: Request For Comments: layout, accesskey attribute, doc

Hi Alexander,

Actually there are several improvements I would like to make to the content module like:

option to keep all history like wikis do
support for multi page content
option to add a threaded discussion
option to add a content rating
tags/categories

I will try to get to those things in the near future.

For now I can either give devs who offer to help with documentation direct edit permission or a private section where they can create and edit content which can be moved to the Documentation tree when it is ready.

Truth is, I have not received much in the way of offers to help with documentation so far. I've gone through recently and filled in some of the missing documentation and other places I have put a request for someone to volunteer but no-one has volunteered.

Cheers,

Joe
6/24/2006 7:38:58 AM
Gravatar
Total Posts 18439

Re: Request For Comments: layout, accesskey attribute, doc

Hi Alexander,

I've been reading up on Access Keys and now I'm doubting whether it is a good idea.
There seems to be a consensus out there that while the intention is good, it actually does more harm than good for the users who we think we might be helping because it tends to interfere with keyboard shortcuts that already exist in browsers for handicapped people. It might be appealing for people who just prefer not to use a mouse but the benefits in terms of accessibility are questionable.

The recommendations I'm seeing are to use a Skip links approach instead of access keys.

Here are some of the things I've read:
http://www.nomensa.com/resources/articles/access-keys.html

http://www.cs.tut.fi/~jkorpela/forms/accesskey.html

Joe
6/24/2006 8:13:26 AM
Gravatar
Total Posts 23

Re: Request For Comments: layout, accesskey attribute, doc

I also know the problem with the interference of shortcuts... but I haven't thought about handicapped people, which have to use a screen reader or a braille interface. As far as I know they have special plugins/tools, which parse and filter the content before they "see" it. So these tools - I think - filter also the accesskey shortcuts so they don't interfere with the generic shortcuts of these people.

Accesskeys are especially for admins very useful because when they begin to built a site with mp, they have to do a lot of monotonic actions like "change, save, see the result, change, save, ...". For such actions accesskeys are indeed very useful. Also wikipedia.org - which surely don't wont to exclude handicapped people from using Wikipedia - uses accesskeys. Maybe we should implement accesskeys just for admins? Many professional users rely on such stuff like accesskeys and web applications like Google's mail service, that want to replace classical mail clients like Outlook or Kmail, uses accesskeys too. But however you're the chief architect! ;) Everybody can implement the accesskey feature in it's own installation of mp.

Thx for the links! The "skip links" feature is very nice.
6/24/2006 8:27:43 AM
Gravatar
Total Posts 18439

Re: Request For Comments: layout, accesskey attribute, doc

Maybe making it optional is the way to go, we could have a siteSetting whether to turn access keys on or off.

Another complication I'm wondering about is how to convey to the user what the Access key is since the browsers don't give a clue like they should. Seems like a pain to add separate labels to indicate the access key.
Also I wonder how to handle it in terms of localization. I might have a Save  button and make S the access key but when it gets translated to another language, S might not be appropriate. Also we would want to avoid using letters that are already shortcut keys in the browser like F, E, G, B, T, and H in Firefox. Using numbers seems less than friendly to me. I don't assume that because a big name like wikipadia is using access keys means it doesn't interfere with special browsers either so I'm not conviced we can ignore what these articles are saying. Its very easy to fall into the trap of just do what the standards recommend without considering the real world impact. Sites like Amazon.com don't seem to have access keys and surely they don't want to leave out blind people either.

It wish it was a clear cut thing but it seems rather problematic deciding what the best thing to do is.

.NET 2.0 has features for both Access keys and skip links built right in so it should be easy to do whatever we decide but I'm feeling mixed about it right now.
6/24/2006 8:32:19 AM
Gravatar
Total Posts 18439

Re: Request For Comments: layout, accesskey attribute, doc

I could be wrong maybe Amazon does have access keys. How can you tell what they are? I can't tell on wikipedia either.
6/24/2006 8:38:28 AM
Gravatar
Total Posts 18439

Re: Request For Comments: layout, accesskey attribute, doc

Also, for admins who don't like to use the mouse doesn't it already work? You can tab until the button or link is highlighted and then hit enter. Shortcuts might help if they are obvious but how to make them obvious and avoid interfering with built in ones in different languages seems problematic.
6/24/2006 8:53:14 AM
Gravatar
Total Posts 23

Re: Request For Comments: layout, accesskey attribute, doc

Optional accesskeys are maybe the best solution.

A common solution to give people a clue is via the title attribute like title='Save changes [Alt + S]'.

Well the localization problem...: I've tried to use German Wikipedia accesskey sourtcuts with a Russian keyboard layout - it didn't work. I've assumed that to access an en_US (qwerty) "Alt + Z", you must press on a de_DE (qwertz) keyboard layout "Alt + Y" (works). But you can't access "Alt + Z" with a ru_RU (??????) Russian keyboard layout via "Alt + ?" though it has the same position on this keyboard (tried with Firefox). Also in Opera there is no "Alt" prefix but a "Ctrl + Esc" prefix for accesskeys. Wikipedia have manged to alter the title depending on the browser you use.

Accesskeys are a difficult to implement feature indeed - but nevertheless a nice one for people, who have to work with a web application diurnally (e.g. Gmail).

The "tab solution" as a replacement for accesskeys...? I would never use it, because it's slow.
6/24/2006 9:12:56 AM
Gravatar
Total Posts 18439

Re: Request For Comments: layout, accesskey attribute, doc

I see your point on the tabbing, that can be a pain. I'll ponder on this and see if I can't grok a good solution for using access keys and maybe also skip links.
You must sign in to post in the forums. This thread is closed to new posts.