Firefox Mobile Browser

December 22, 2009

Fennec, the mobile version of Firefox, should be with us in a few days.

The BBC reports:

The first mobile phone version of the popular web browser Firefox is “days away” from launch, the head of the project has told the BBC.

The browser, codenamed Fennec, will initially be available for Nokia’s N900 phone, followed by other handsets.

It will later be available for Windows Mobile and Android, however it will be some time before we see it on the iPhone (if at all).

One thing which makes it interesting

The open-source browser will be able to synchronise with the desktop version.

This means you can move from mobile to desktop and back without having to worry about where you were.

As I don’t have the Nokia N900 it will be some time before I get to have a proper look.

Advertisements

e-Learning Tech Stuff episode #001 – Removing your browsing history from the Asus EeePC

May 14, 2009

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.

Download the iPod version in MP4 format.


Fennec – the Mobile Firefox Browser

December 17, 2008

So you like mobile devices? So you like Firefox as your main internet browser?

Well now you soon be able to combine both in Fennec – the Mobile Firefox Browser.

Mozilla user-experience designer Madhava Enros conducts a tour of the alpha release of Fennec (Firefox for mobile devices).

Vodpod videos no longer available.

more about “Fennec Alpha Walkthrough on Vimeo“, posted with vodpod


e-Learning Stuff Podcast #008 – Forcing the windows open!

November 23, 2008

e-Learning Stuff Podcast #008 - Forcing the windows open!

This is the eighth e-Learning Stuff Podcast, Forcing the windows open!

Download the podcast in mp3 format: Forcing the windows open!

Subscribe to the podcast in iTunes.

In this show, James is joined by Nick Jeans, Kev Hickey, Dave Foord and David Sugden.

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…

Shownotes

Photo source.


Forcing windows open

October 28, 2008

Here’s a question?

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
window” approach.

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.

Forcing windows open

Other sources on why you should never force new windows on users.

Check point #2 on Jakob Nielsen’s usability website.

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.

Another view from Sitepoint.

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.

Do you have a view?


Google Chrome and Moodle

September 4, 2008

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.

Google Chrome and Moodle

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.

Google Chrome and Moodle

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


Google Chrome

September 3, 2008

Google have gone and released a browser of their own, Chrome.

Windows only at the moment, so I have not yet installed it.

Looks interesting.

Alas I have heard that Moodle does not work with Chrome, so that’s one thing I will be checking out.