Slashdot Mirror
Future Directions Proposed For Mozilla
Ars-Fartsica writes "MozillaZine is now featuring a set of slides regarding future directions for Mozilla that were detailed at the recent Mozilla developers meeting. SVG and integration with programming languages are among the directions discussed."
They've been working on SVG for a long time...
Why the heck isn't it included in the default build already?
SVG's gonna be killer when we can actually use it (and count on users being able to use it too)
Yup, and that appears to be all you can see if you run with Javascript disabled. Good job, guys!
Gotta love that "degrade gracefully" concept.
Why do you want to integrate everything? You integrated mail, news, irc, calendar and probably million of other shits I never used in Mozilla. What is so amazing in one integrated monster? Do we really need to follow Microsoft path? I always though Unix way is to build many small tools, not one big piece of shit.
This is more than a cosmetic issue. Mozilla has the OK and cancel buttons in dialog boxes in the "wrong order" compared to the rest of my desktop, and so I frequently find myself hitting the wrong button by reflex. I also run into bugs in the mozilla widgets all the time. Try middle-clicking on the scroll bar of a textarea widget (under X): its supposed to absolute-reposition the scrollbar; it does that, but in addition pastes the clipboard into the textarea! Another benefit of native widgets would be to decrease memory usage, since the widget libs in memory would be shared.
Its nice they've been listening to their users.
--
Wanna play some word games?
A more flexible toolbar (ability to stack toolbars left and right and not just up and down).
If you're going to compete with IE, javascript is the way to go. Start with matching the functionality (IE the ability to reference objects without needing to go through getelementByID the way you can in the MS browser, this will eliminate 90% of the javascript incompatibilities between the two browsers).
3] Realize that as far as the end user is concerned browser rendering technology is done and will be done until there's enough bandwidth for full motion picture browsers (Think tivo on steroids). Adding more features just adds to bloat for very, very minimal gain. To that end the focus should hinge on a better, more intuitive interface -- the more you can make it disappear while still providing easy access to navigation and google the better. And don't forget the art, IE still makes pages look better that definately needs to be fixed.
4] Firefox and Thunderbird are killer apps but Thunderbird especially has a lot of room for improvement. When Thunderbird can piece together split usenet files and handle Y-ENC then it will probably truly have arrived for many usenet junkies. After that you need to out exchange exchange and realize email is a centeral pda application and to that end we need scheduling, address books that sync with our newtons, and help us manage our lives. Indeed, do Thunderbird right and you can really shake up the world because there's a real hunger and need for an ultra powerful email/usenet/scheduler/contact/pda manager.
I mean the standards that Microsoft sets for the web.
Do you mean the standards that were set by the PC implementation of IE or by its mac implementation? These are vastly different, you know? No, I suppose you don't.
A question: Does Mozilla/Firefox/Phoenix really need to do this itself?
Something like this is ultimately a gamble which may or may not pay off...and if it doesn't work, there's a huge amount of cruft dumped in the codebase?
I'd rather see something like the approach Apple used with KHTML in making Safari. If someone wants to make a program called, say, "Mozilla Platform" that *uses* Mozilla, I think that'd be a lot safer than trying to make one massive integrated push.
I think that trying to integrate everything has been the largest problem facing the Mozilla project. I have, many times, contributed patches to open source projects. I have never contributed to Mozilla, because the project was (at least to me) very large and overwhelming...and I only really cared about fixing problems that affected me. If I ran into a problem, it was often something that would require learning a huge amount about how Mozilla is structured to fix. I'm okay spending a day or two fixing a minor problem on a project that's irritating me. I'm not willing to spend a week doing so.
The "integrated" approach is a turn off from a resource standpoint. It made the Mozilla suite large from a disk and memory usage standpoint.
It meant that releases had to be spaced widely apart, and that one broken component could hold up releases of the rest of the package.
It meant that you had to lug around a mail client, web page design program, etc that you might really not be interested in.
In general, I think that Open Source does better if taken in smaller chunks. It makes rewrites and bugfixes more localized, it lets users choose the best option for them (rather than using that mail client that's bundled and always in their face), it keeps resource usage low, and it lets developers release on a more timely schedule.
May we never see th
Much as I hate to admit it, and as strongly as I feel that rollover highlighting is a flawed UI concept, enough websites rely on rollover capabilities being present in a browser that it may be rough to disable them.
On the other hand, I think there there are few compelling reasons for allowing websites to modify the status bar information. Doing so is a serious security issue. Users (well, they won't think in about this in rigorous terms, but they do so unconsciously) treat the status bar as a source of trusted communication between their browser and them. If remote websites can muck with it, they lose the ability to trust that area.
I suspect that there are more sites that break with popups disabled than with status bar text and rollovers disabled combined...but we still do it. The main reason remote websites have so much control over browsers today is because of a Microsoft-started prescedent of trusting websites, of treating web developers as application developers. They aren't. Every website you visit just plain isn't trusted, and there should be much tougher rules on what websites can do to a browser. Allowing a website to, say, change the appearance of widgets is, IMHO, unacceptable.
May we never see th
A browser that kills your machine every hour? I suppose it will be all the kernel level drivers that Mozilla installs that cause that. Oh wait, it doesn't have any. Mr Senior IT Manager for a Corporate, you should know that a userland app should never be able to take down an OS, Windows or not. And you'd know that more often than not, XP is configured not to display a blue screen, but just to reboot. My advice? Check that it is configured to stop on a crash. Apply all the patches. Disable services you don't need. Use Firefox again, and see if it crashes the OS. If it does, make a note of the info on the blue screen, and Google for it. Try swapping the memory/cpu with another similar machine.
But don't go blaming Firefox for crashing your machine.
Get your own free personal location tracker
But to make it a standard on the web, Mozilla has to want it.
It doesn't matter if only a part of it is implemented, html or css isn't 100%ly implemented either, so include SVG in the default build
SVG support is already good enough for most uses.
I can tell users to "download Mozilla version x.y or above", I can't tell them to "download that special SVG-build, but you won't get any localization and everytime you upgrade you will lose SVG".
So the sad state of affairs is that solely because of political reasons SVG in Mozilla is completely worthless and I would advise users to download the Adobe plugin instead.
Konqueror comes with SVG-support out of the box in the default build and it's what I already use for some admin interfaces (where I am the only user) to rotate text (a real shame that you can't do that with HTML. But it's currently the only use I have for SVG and Mozilla could do it if they wanted to.) - because even I am too lazy to mess with specialized builds for Mozilla.
I've tried the SVG-build half a year ago and it was at that time working really well and was technically probably better than Konqueror's current implementation. But because of moronic politics, SVG in Mozilla will continue to rot away completely useless in real life while Konqueror will have lots of SVG users (and bug-reporters) and will improve fast and overtake Mozilla soon.
There were times when Mozilla was really leading development, unfortunately the Mozilla project got obsessed with the idea to dumb everything down and even throw out advanced features (like MNG support!). The future belongs to KHTML and Konqueror, that project has dynamics, the will to improve and is not hindered by politics. Apple has seen that and that's exactly the reason why they chose KHTML over Gecko, IMO.
That all said, I really hope that Mozilla wakes up and proves me wrong. Mozilla is currently the only real cross-platform browser, which is a great advantage over KHTML. Gecko is also a great rendering engine. Include SVG in the default build. NOW.
This sort of issues occured on various computers I've worked on in the past due to faulty video card drivers.
And as others have pointed out, a user space program by itself shouldn't be able to crash the whole system (not even on Windows)...
So the sad state of affairs is that solely because of political reasons SVG in Mozilla is completely worthless....
Care to back that up? I always assumed SVG wasn't included by default because it added bloat, not because of "political reasons".
The shareholder is always right.
To all the above posters - this is an INTERNAL document which happened to be released to the public. There is no reason to think that they would make it pretty for other browsers when they only ever intended to properly use it once, and on a Mozilla browser.
Free iPods - now in the UK!
Is Mozilla "finished"?
Have the startup speed problems been solved?
Is Mozilla as robust as they would like it to be?
Why not stamp out all of the performance issues before thinking of moving on?
Those issues are *THERE* .
If Dillo ever got finished you would see people dropping Mozilla like an Atkin's dieter dropping a hot potato.
Peformance still counts, even if you try bribing the end user with nice features.
Steve
Two major issues:
* The first is an element in the Apple HIG. While the HIG is not a "textbook to HCI", it has very good, well-developed suggestions, and arguments against guidelines in it should probably be well supported -- Apple was famous for a decade and a half primarily on the strength of the content in the HIG. The Apple HIG states that program state should not change based on the location of the mouse cursor alone -- a mouse button should be pressed to indicate that an action is taking place. The reason? The user always feels that he is in control and can move the mouse around without causing anything to happen. It also means that he does not need to wave the mouse to operate a program. Note that this guideline has been broken before by Apple in the form of Balloon Help. Basically, not changing state is important to allowing the user to feel in control of the computer, and free to move the mouse as he desires.
* The second argument was from a major HCI figure, though I cannot remember whether it was from iarchitects or from something from Jakob Nielson. I rather wholeheartedly agree with the sentiment. "If your interface does not immediately make apparent what is clickable and what is not, and you need to insert rollovers to make things clear to the user, you have failed to make an intuitive interface." The idea of *having* a desktop with possible choices to click on available is that all choices are immediately apparent. An interface that requires rollovers requires the user to move the mouse around to determine what is clickable. We have standardized interface elements so that it's easily apparent how things work at a single glance from the user. Falling back to visual identification via rollovers is a big step backwards.
Rollovers became popular starting sometime in the
"multimedia era" when CD-ROMs were coming out, and there was loads of Director-produced custom interfaces being produced by graphic designers. They ignored the standard widgets, and Photoshopped up their own. Unfortunately, it was frequently difficult to figure out when something was even a *control*, and so they had to provide rollovers.
The second major boom came when big images with imagemaps started becoming popular on the Web, and graphic designers started getting paid good wages to produce websites. All of a sudden, a bunch of pages were covered with huge images with knobby things, metallic things, slider things, little ridges, dimples, rectangles, and whatnot. Some chunks of these interfaces were clickable and some were not. They were essentially unusable without rollover highlighting and the user waving his mouse around each page to figure out what was a control.
* I have a third and final argument, which comes simply from me, though I'm sure it's not original. I find animation to be something that should be strictly reserved for important attention-getting. Short of making noises (which is disruptive in, say, an office environment), there are few other good ways to attract the user's attention without grabbing control of the environment and slapping a dialog up in front of everything else (something to be avoided if at all possible). There have been few sanctioned uses of animation in Apple's history (again, I use Apple as an example because Apple traditionally had very good UI work). One of these is the "barber pole", or equivalent of the progress bar for tasks with an unknown completion time. I believe that the only other animated elements are menubar flashing (to visually indicate a beep), application menu flashing (to indicate an error status), and ZoomRect()-style animation to indicate the source of an item being opened. Except for the barber pole and the application menu flashing (which indicates a fairly serious condition), all are directly triggered as a result of user input and are quickly over over. This reserves animation
May we never see th