We have decided to deploy some Asus EeePCs in our college Libraries as short term loan computers to provide extra access to computing when we are busy and for those learners who want a smaller computer footprint when working on their learning.
One thing that learners may want to do is remove their browsing history from the EeePC to ensure that all cookies and password are removed.
This simple guide shows how to remove the browsing history from an Asus EeePC.
In this the eighth episode of e-Learning Stuff they discuss the pros and cons of forcing links to open in new browser windows. In that discussion they cover accessibility, usability, links, legal implications, frames and then some…
When you design a website with external links, add links to your VLE, do you force the link to open in a new window or in the same browser window?
For me forcing new browser windows open on the user is both poor practice and annoying for the end user.
Rather than do that use the following text next to any link.
To open link in a new window right or ctrl click and click Open in a New Window
Forcing new windows breaks all web usability guidelines and creates problems for users and importantly affects accessibility issues. International user accessibility guidelines recommend against the “new
When a new window opens in front of the old one a novice user is likely to think that the “back” button associated with the new window will take them back where they were before, and doesn’t know what to do when it won’t, this can be just as annoying as closing the whole window.
Confident users can cope with the forced new window, new users can not.
Similarly a disabled learner, using a head pointer or other assistance device, won’t be able to simply click on the back button to return if the code has forced a new window to open.
This could be a significant problem for many learners suffering from quadraplegia, other disabilities or visually impaired learners.
Also Firefox has an option which actually stops new windows from happening.
Other sources on why you should never force new windows on users.
Opening up new browser windows is like a vacuum cleaner sales person who starts a visit by emptying an ash tray on the customer’s carpet. Don’t pollute my screen with any more windows, thanks particularly since current operating systems have miserable window management). If I want a new window, I will open it myself!
Designers open new browser windows on the theory that it keeps users on their site. But even disregarding the user-hostile message implied in taking over the user’s machine, the strategy is self-defeating since it disables the Back button which is the normal way users return to previous sites. Users often don’t notice that a new window has opened, especially if they are using a small monitor where the windows are maximized to fill up the screen. So a user who tries to return to the
origin will be confused by a grayed out Back button.
Here are the top 5 reasons why you should beware of opening links in a new window:
Unless you warn them, Web users are likely to expect the new page to load in the current window. Unexpected surprises can be fun, but not when you’re browsing the Web.
The act of opening a new browser window resets the back button in that window. The back button is the second most used navigation function (after hyperlinks, source: useit.com), so resetting it is a big no-no.
To open a new browser window can disorient very novice Web users and the visually impaired. They might not realise that a new window has opened and might struggle to switch between windows.
Opening a new browser window disrespects the desires of your users. If they want a new window, they’ll ask for one. Don’t force a new window upon users unless there’s a very good reason to do so.
New browser windows can make an already cluttered taskbar even more difficult to use. We’ve all spent ages hunting through the taskbar in search of the window we want. Don’t make this process even harder by increasing the number of windows the user has open.
In my last posting on Chrome I mentioned Moodle issues with Chrome which I had picked up from Kev Hickey’s note on Jaiku.
I have now installed Chrome (on Vista running in VMware Fusion on my iMac) and is running smoothly and very fast as well.
Tried out the Gloucestershire College VLE (we run Moodle 1.5.4) to see how it worked.
Logged in fine, but as you can see in this screenshot when you try to post a disucssion topic (or a wiki page or a lable, etc…) you don’t get the WYSIWYG HTML editor.
Now if you know your HTML you could format that way, but with a wiki page, are all learners going to know HTML, I think not (as does Kev).
The problem is twofold.
Firstly Chrome uses the same backend browser, WebKit, that other browsers such as Safari uses. You have exactly the same issue when accessing Moodle in Safari – which is why I always use Firefox on my Mac when editing the VLE and adding discussion topics on the VLE.
So why doesn’t the HTML editor in Moodle work in WebKit?
This is the second problem, the HTML editor is an old editor which has been discontinued. Newer HTML editors exist which do work in WebKit browsers such as Safari and Chrome.
The answer from browser developers appears to be, update your web sites and applications!
Eventually things will work fine, as Moodle 2.0 uses the newer TinyMCE HTML editor which does work in WebKit browsers.
So if you are using Moodle you may want to avoid Chrome until your Moodle installation is upgraded to Moodle 2.0
Engadget reports on the release of Opera Mobile 9.5.
Today, it’s out for a beta 1 launch. In other words, it’ll be buggy but likely far more useful than the browser already installed on your touchscreen-based (PocketPC) WinMo professional phone. The initial release includes support for double-tap zoom, landscape flip, off-line page save, tab-like browsing, auto-URL complete, and a Google-search bar to name just a few of the 9.5 features.