“The DS Browser ends up becoming a bullet point for the Nintendo DS system’s capabilities. Yes, the Nintendo DS can now surf the internet. But after the novelty wears off, you probably won’t want to”, Craig Harris writes in his review. Craig was very kind to send us a DS screenshot rendering the mobile version of OSNews, although the browser seems to interpret “100%” of cell width as 800px wide instead of DS’ 256px native resolution. Update: Craig sent us another shot, this time using the “small screen rendering” mode, which looked much better.
Certainly seems to be the gimmick I thought it was, now that some of the hype has cleared and people have been putting it through it’s spaces. Even the 4MB expansion is pitiful for displaying web pages. I had a Nokia 770 and it’s 64MB wasn’t even enough!
Yup, I have blogged about web browser memory problems on embedded devices here:
http://eugenia.blogsome.com/?s=verizon (search for the word “verizon” if the right article doesn’t come up automatically by clicking the link)
Depending on the browser, you need at least 15-20 MBs of *available* RAM to get a good experience out of web browsing these days. And this number is going to go up as more sites move to CSS-only (rendering complex CSS layouts requires more CPU and RAM rather than when rendering plain HTML).
On the other side, if layout is only (ie correctly) done in CSS, you can have a very good view of every website without considering much of the CSS.
So it should be more easy to write a lightweight browser giving a good view than with older, heavy html, designs.
Lynx is a very good test if a website was done right or wrong…
I am not sure I understand you. Creating a css-only browser is not easy, it’s in fact more difficult than having HTML 4 support. And a CSS-only web page takes A LOT of CPU. And it won’t be compatible with the BULK of mobile/embedded/text browsers. This is why osnews will remain cHTML.
And Lynx is terrible, although very popular. If you want a good text-mode browser try ELinks.
Well, if a page is done “right”, the structure is in the html, whereas the design is in the css. Now it is easy to ignore the CSS and still have a good structured page. Next thing would be to accept colors from the CSS, perhaps some framings, and graphics. This is not heavy yet. You can get rid of exact measurements and sizes.
Sure there are more decent text browsers than lynx. I just wanted to point out that a good designed website can be very good readable _even_ on lynx. Now put some graphics support and what I wrote above into lynx and you have a primitive browser, which still gives relatively good looking and for sure good readable output.
Problem is, this really works well with _only_ good written html pages (where _every_ design thing is in CSS!).
For example, this website gives high CPU load (because of the transparency thing):
http://pong2.berlios.de
Still you can have fun with it with “every” primitive browser, too.
<blockquote>The browser doesn’t support a lot of Internet standards: no Flash, no movie files, no images other than .GIF and .JPG (and possibly .PNG), no Java</blockquote>
Sounds like heaven to me…
you’d think he might consider testing its PNG capabilities before writing the review, it would be interesting to know for sure.
damn you OSnews, that worked on the JS preview!
but given the fixed layout of the sites html, SPECIFICALLY:
<table width=”765″ border=”0″ cellpadding=”0″ cellspacing=”0″>
<COL width=”155″>
<COL width=”610″>
Opera rendered in ‘normal’ EXACTLY as it should… It should ONLY display properly on <800 pixel displays in opera with ‘Fit to width’ / ‘Small Screen Rendering’ on.
Which I still say fixed width is just bad site design. Remove the width= on the table and the second column, and make the site actually USE the clients browser window instead of crippling it on small screens, and making it a crappy little stripe down the middle of the screen on larger ones.
I am sorry, but you didn’t get it right. The mobile browsers are AUTODETECTED on osnews and they are served a DIFFERENT source code. Didn’t you see in the screenshots that it looked different than the version you quoted?
The mobile version of osnews has width 100%, not 765px.
Edited 2006-08-19 05:00
>> I am sorry, but you didn’t get it right. The mobile browsers are AUTODETECTED on osnews and they are served a DIFFERENT source code
My bad, although that seems like an awful lot of effort when you could probably just write once and be done with it. (well, except for WAP which should get it’s own since that’s not HTML)
Hey, at least I didn’t do the XHMTL fanboy ranting and raving about how you used tables for layout.
Given how it rendered though, I would wonder if there isn’t some element on the page pushing it to that limit – the odd spacing of the navigation table for example makes me think something’s not kosher there.
Do you have any cgi flags in place that can ‘force’ OSNews into feeding specific versions? I’d be interested in seeing what the desktop copy of Opera does at various settings (such as the small screen previewer)
> I would wonder if there isn’t some element on the page pushing it to that limit
Nope, it’s all 100%. It makes sense for normal desktop websites for the browser to have such a 800px limit. Pocket IE has this limit too. Webkit on Symbian too. However, when a site does fit on the native res of the device, they don’t stretch to 800. That’s where the bug is. The idea for 800px is correct, it’s just that Opera DS’ implementation needs polishing. My main problem is that other versions of Opera Mobile don’t have this problem.
Well, I just got my hands on one for a couple hours – and I think I found the ‘issue’
It is NOT Opera mobile, but a modified version of full blown opera able to handle full blown XHTML… The browser in normal (non small screen) operation is SUPPOSED to emulate a 800×600 display ‘shrunk’ to fit on the top lcd, and a zoomed in box on the bottom one. Really slick as you are able to send it to most any site ‘desktop’ opera can view and have no problems (apart from scrolling around a whole lot, though the controls for that are fairly intuitive)
As such this site should be sending the DS the full ‘normal’ version of the site, not the reduced.
Well, good work finding the issue, i think it’s been made clear from every preview of Opera DS ever written that it IS NOT just a mini browser like their java product, how on earth are you people managing to become so confused by the matter? are you all browsing with opera mini on mobile phones and are thus unable to see the full photographs in the review?
DeathShadow, you are again dis-representing the fact. You see, as I said above, having such SVGA LCD limit, is the CORRECT thing to do. And it IS Opera Mobile btw. Opera Mobile does have that SVGA limit too, just like PocketIE and Webkit too on Symbian.
But the difference is, that it is not INTELLIGENT enough on its algorithm on how to use this feature. It should make a check and see if the site FITS on the native resolution before it goes all blown away to SVGA. That’s what Webkit does, look screenshot here: http://osnews.com/img/12965/s60-6.jpg This is webkit’s mini map of the whole page. The native resolution of the screen is 352×416, and it DOES also have this 800×600 trick. However, Webkit does it the RIGHT way: it checks first if it fits on its native res before it goes all blow up to SVGA. This is why the minimap is just a long strip instead of a full screen map of the site (like it is in the first opera shot in this story).
And that’s where the Opera Mobile bug is. Not in the fact that it uses SVGA as its max resolution, but in the fact that it doesn’t have a good implementation of it.
Edited 2006-08-20 19:37
>> And it IS Opera Mobile btw. Opera Mobile does have that SVGA limit too, just like PocketIE and Webkit too on Symbian.
No… having used Opera Mobile on a Nokia series 60, I can most certainly say that what’s running on the DS is NOT opera mobile – not even CLOSE.
As to what webkit does – That’s exactly what opera does in ‘small screen’ mode (regardless of the device) – and webkit’s way of doing it COULD be considered VERY wrong… Trying to check the native res of a device less than 640 pixels across when 90%+ of the web pages out there aren’t written to support it is a BAD idea… Which is probably why I prefer Opera to Webkit on Symbian.
I would definately NOT call it a bad implementation of it, given that it works fine with most all EXISTING websites that don’t waste time trying to send some specialized version to mobile computing devices… It assumes you want to see the REAL version of the site – if anything I’d be pointing the finger at your browser detection code server-side for sending the DS the wrong version of the website, NOT Opera’s behavior. Opera on the DS is MEANT to browse the same code as the desktop version with no regard to ‘specialized’ versions for reduced browsers… mostly because Opera is of the opinion (one I agree with) that expecting site designers to waste time coding specialized versions just for mobile devices is impractical, unrealistic, and increasingly unneccessary as the hardware in mobile devices exceeds the processing power of desktops from a decade ago.
But again, that’s likely a matter of personal preference on browser behavior – something NOBODY can really agree on.
>Hey, at least I didn’t do the XHMTL fanboy ranting and raving about how you used tables for layout.
XHTML does not work as well as cHTML does for all the browsers we support. We don’t have this special support only for mobiles, but for embedded and text mode browsers. And these browsers only barely manage to do HTML.
huh, intresting. When you start doing real web work, you’ll know there are just times you have to use tables for containers. The tables on osnews DO encapsulate data, and its a valid use for tables.
google news is an excellent example. also, php.net is all payed out via tables. The simple fact is, you can’t do everything you can do with tables compared to css. Visa versa as well. Its best for any real programmer not to be religious about these type of ordeals.
Nintendo has come a long way since the NES. I find the DS pretty cool. Hope to get one soon. I use the opera web browser on the desktop and on PDAs.
I think I’ll personally get a DS for work purposes. I’ve a wireless network setup at work, I’d find it very nice to be able to control my administrator applications from a hand help device. I’ve thought about the Axim and others, but just don’t want to fork out the money on large devices.
>Which I still say fixed width is just bad site design. >Remove the width= on the table and the second column, >and make the site actually USE the clients browser >window instead of crippling it on small screens, and >making it a crappy little stripe down the middle of the >screen on larger ones.
Fixed width is bad, but the main problem of not having fixed width is, that lots of webdesigns are done by graphics people and they usually are used to doing print layouts, so things like that happen, often you
want to have one column fixed the other resizable, you need a fixed width attribute, the proper way of doing this would be css not tables, but as long as several resizing css attributes are broken you have to do it the old way and have to face it that browsers with small screens run into problems. (have you ever tried to do a decent table free css only layout without any hacks which should also be able to resize and adjust? Good luck especially if the whole thing has to run on the IE.
Anyway back to topic, the loading time looks severely like everything is routed through a big firewall of nintendo, as the article notices, opera for mobile devices is not that slow, there must be something else fishy going on. Now given the fact that Nintendo tries to be “family friendly” they probably really route everything through a proxy so that they can block content upon request, it would make sense (for them).
it may just be that the DS is trying to handle the full version of the website whereas opera mini is fed through opera’s converter to sanitise it for use on small screens, the DS has a lot more work to do, first rendering and then scaling full web pages, and not much memory with which to do it
I have two Nintendo DS Lites (the previous model was too bulky for my liking) and Opera is currently my favourite desktop webbrowser.
My cellphone operator T-Mobile now has more than 600 free Nintendo hotspots in the Netherlands, hopefully this will further increase as browsing at home with a Nintendo DS instead of using my PC doesn’t make much sense to me, but online gaming is nice though. But if I can freely browse the web for checking the latest news and my emails while travelling by train (airports are already supported) it would become an excellently useful feature to me. My cellphone’s screen is just a bit too tiny and a laptop is not appealing for me for taking with me while i.e. going on vacation.
This might be useful for some people like me who don’t have PDA or cell phone capable of usable web browsing, but do have a DS, but it’s certainly not a reason to get a DS.
I have Opera Mini on my mobile phone and that is far from slow, it is faster than every other included browser I have seen so far.
So it is hard for me to believe that the Opera team messed this one up.
Let’s see what other reviewers will say, especially if they have a version in their native language.
Opera Mini is not the same as Opera Mobile.
I know that Opera Mini and Opera Mobile differ a lot. Yet what I meant with my comment is that I see the Opera guys as guys with a lot of experience.
So I would be surprised if they would mess up Opera for DS.
Sometimes they don’t have the ability to make it right. If you had read my blog post I linked it explains that manufacturers don’t always offer enough RAM and CPU to offer a good experience. It’s not always the fault of the browser developer but the device’s.
Opera Mini doesn’t get the data from the website, it get’s it from an Opera server that preprocesses the data (e.g. sizing down the images). It has less data to download and less code to render (and Opera sees all the websites you are surfing but that’s another topic).
Opera DS however deals directly with the original data from the website like a browser on a PC does. But it’s hardware is much more limited.
That’s why it’s so slow compared to Opera Mini.
It appears to not be 800 pixels fixed, but detecting the content, assuming 100% as 800 pixels if no other numbers are declared…
Case in point, the screencaps from the IGN site are of the normal HTML content, not a mobile browser version… Their normal site is designed for 1024 across.