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.
do you have a specific problem in mind?
Mozilla is too damned slow and takes too much memory implementing all of its own widgets. Why did they think this was a good idea? Seriously, just asking because I'm curious why.
"Web standards stagnating due to MS monopoly"
w .mozilla.org%2Fevents%2Fdev-day-feb-2004%2Fmozilla -futures%2Ftitle.html&doctype=HTML+4.01+Transition al&charset=iso-8859-1+%28Western+Europe%29
... umm.. yeah alright..
http://validator.w3.org/check?uri=http%3A%2F%2Fww
... fully features operating platform with multiple language support, x-bell and y-whistle.
... they care how big the browser it is to download.
Too much focus on the details, too little focus on direction. IMHO, a common problem without non-developers looking at user requirements. x-user doesn't care if Microsoft is a monopoly
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?
What other benefit besides native browser support will SVG have to use against Flash
I don't know about anyone else here, but I'm sick of advertising in the form of flash. I sure wish there was a way to have the flash plugin work like the popup blocker does. Where I enable it for certain sites, but leave it off otherwise. Until then, its gone from my browsers. Bring on the SVG.
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
The thing is, nobody using WYSIWYG web-design tools really cares what the output looks like, as long as it's valid HTML that looks OK in most browsers. Anyone doing 'serious' web design is going to use a 'serious' WYSIWYG web design tool, btu the built-in editor in Mozilla (or any browser) isn't meant to be that. It's meant to be something that'll make an OK Geocities/Angelfire/MyRandomSuckyISP page that has a a few pictures of my cat and my girlfriend on it
It's essentially the same reason that Pico lives on while Vi/Emaces still exist; some people just want to get the job done and don't really care about having any power.
my sig's at the bottom of the page.
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.
I use three different proxy settings depending on where I am and what network I'm on, or in some cases (like auth for hotel/airport high speed access), no proxy; it's annoying as hell to change these settings, as they're buried deep in the preferences.
At a minimum, it'd be great to have a "Proxy..." menu item that went to the proxy settings directly. At best, perhaps a proxy manager with associated easy UI access (sidebar, hierarchical menu item) that would allow you to switch proxy profiles on the fly without wading into a preferences dialog.
To be fair to Mozilla, it's at least less buried than IE, but unfortunately not much less.
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!
Perhaps, but after looking at the 700+ page spec, which, by the way, has dependencies on almost every spec ever issued by the W3C... I kind of doubt it.
A 700 page spec that reuses W3C specs still beats Flash, a complex binary format that nobody supports.
To be a bit more specific, SVG encompasses so much that a fully compliant implementation must support not only the massive spec, but also ECMA Script, SMIL, MathML, etc.
Yes, and the same functionality is present in Flash (when it isn't, as in MathML, it's a deficiency). Now, when you try to do your own implementation of Flash, you have to start from scratch, trying to implement Macromedia's counterpart to ECMA Script, SMIL, etc. How is that better? At least with an SVG implementation, you can reuse existing ECMA Script, SMIL, MathML, XML, etc. tools and implementations.
Furthermore, there are several levels of SVG. I suspect most implementations will rely on the simplest level, which is a straightforward, modern vector graphics format based on XML, something that the world really does need. And it is a need that Flash does not fulfill.
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
In my experience, repeatable crashes in Windows from programs doing non-crash-inducing things are generally caused by (1) flakey video drivers, (2) other flakey drivers, (3) bad RAM, (4) bad video hardware. If Firefox runs on thousands upon thousands of computers, yet crashes only on yours...
...well, whatever's causing it, it ain't Firefox.
Range Voting: preference intensity matters
You may be kidding here, but I was amazed to see how many people, web developers, people with a clue so to speak, still openly prefer to use Internet Explorer. I honest to God fail to see why. I understand that a clueless user would use whatever is put in front if him. But a knowledgeable developer?
I've seen co-workers and aquintances do it. One of them spent half a day finding spyware and trojans with Ad-Aware and similar tools. He found over a hundred items, most of which were IE related. He used Mozilla for a day or two, quietly agreeing to all its fine points I was underlining. Then on the third he was back to using Explorer. He just stared at me blankly when I asked why.
Another guy I talked with on a forum said he "feels" that IE responds the quickest on his system, so he's willing to overlook the popups, the inability to block ads, the lack of tabs, the flaky security, for this. "I'll just wait until MS implements popup blockers and tabs", he said.
A third guy was quick to point out that IE is perfectly usable "as long as you also use a firewall, a good antivirus and some kind of proxy such as Promixtron". Great. So I have to use 3 additional pieces of software on the same system just to make up for one crappy browser. Go logic!
I'm telling you, it's more than just using the browser you find preinstalled. I'm guessing some kind of brainwashing is involved after all.
i ate crayons when i was a kid and now i have two braincells and the blue ones taste nicer
That's exactly the reason I'd recommend using Firefox on Windows because it doesn't use the IE libraries.
Though IE is convenient, it's also built into windows and is a fragile system component liable to jeaopordize many more things in my OS if it breaks or becomes corrupted. It's seemingly constant updates, standards tweaking, and security fixes mean that the code base is quite volitile.
For the sake of the security and functionality of my system, I've found things run much better if I intentionally do NOT use IE (or a similar program that just calls the IE libraries) and instead use something independent like Firefox.
I'm not saying that IE is broken, but like a child that isn't ready to deal with all of the diversity seen on the world wide web I'd prefer to use it only when called to work it's magic by other apps for things on my machine. I'll keep using another browser like Firefox that's more mature in its development and can handle the deviant standards people use to write their html code more gracefully.
The absolute refusual of the mozilla team to implemente broken javascript. That's what keeps me using IE for the few internal apps I have here that refuse to work with any other browser.
:-/
That and java support, something that again, 90% of 3rd party developers cannot get right without using IE.
<sigh> Don't let the moz team take the low road. Don't support broken standards! Just grab your local clue-by-four and start hitting people who write broken web code.
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
I really like many of the ideas presented in the roadmap.
But what would be really nice to see, too, are some estimates of what the biggest costs are alongside the benefits. That is, in terms of development roadblocks, obstacles. Some of the ideas, such as SVG I really like, but suspect there are huge development costs involved.
By putting out some estimates of how much effort and what kinds of expertise the different projects will require, developers will have a better idea of where they can contribute and how much effort they might have to put in before seeing some tangible results.
"Provided by the management for your protection."
Server-side applications are possible, but getting them to play nice is a problem, mostly due to security issues. Also, if your application uses anything compiled, it would have to be on the user's computer anyway. The best is really having hybrid standalone applications using the GRE, with anything compiled on the computer and everything else on the net.
Christopher S. 'coldacid' Charabaruk -- coldacid.net