Slashdot Mirror

You can install them from Firefox by going here and here.

I wish they'd just get it over with and fully disown Thunderbird so that others who do give a damn can do something with it.

You seem rather unclear on the concept of open source. Anyone who cares can contribute to Thunderbird development. Anyone who has a better idea for its direction can take the code and fork it, even turn it back into a commercial product. And they have, there's a list of e-mail clients based on Thunderbird on Wikipedia, one of which is Postbox for $30.

Only in the minds of entitled armchair whiners does Mozilla paying salaries for Thunderbird engineers and even a messaging team for years somehow equate to "not giving a damn." The reality is there's little interest and clearly no money in a standalone e-mail client, and it's somewhat tangential to Mozilla's mission. As users moved to web mail and ISP-provided clients, Mozilla's various experiments to do cool collaborative and communication things with Thunderbird didn't have much impact.

(I've used the SeaMonkey browser-editor-mail-IRC suite since it was Netscape Navigator 2.0. SeaMonkey 2.11 remains a solid useful product with all the performance and memory wins of recent Firefox, and I really appreciate the talented few who keep it going with the aid of Mozilla's infrastructure.)

Agreed. It's fashionable to decry any new UI ideas as stupid. And indeed many UI redesigns are a step backwards, or purely aesthetic, or confusing, ... I'm not a fan of Unity, for instance. But we have to be at least somewhat open to new UI ideas, or computer interaction will never move forward.

This particular idea seems really good to me. In fact it's something I've been wanting for a long time. There have been small pushes in this direction (e.g. the Ubiquity add-on for Firefox would let you type commands (like "map XXX" or "email page to XXX") and get immediately useful results), but for it to really work, from a user perspective, it has to be available in every application so that it's worth the cost to learn the new style.

Being able to search the menu structure is really powerful, especially for applications with loads of commands (photo editors, word processors, etc.). I've lost count of the amount of time I've wasted searching through menus for a command that I use infrequently. I know it exists, I've used it before... but does it count as a "Filter" or an "Adjustment" or an "Edit"? Why can't I just search for it? Moreover, I shouldn't have to train myself to remember where it was put. Once you get used to typing commands, it can be extremely fast to do so, becoming almost as fast as a keyboard shortcut. (Obviously this will be more the case in applications where your hands are already on the keyboard, like word processors; it could be slow in applications like photo-editing where your hand is usually on the mouse...)

The ability to rapidly invoke commands via the keyboard is something that I would think most slashdotters would love: it adds back in some of the power of the commandline. It also inherently streamlines across applications (you should be able to just type "Save" or "Preferences" in any application and get the expected behavior, regardless of where they put the menu item. If they're smart, they'll kind synonyms, so that "Options" and "Preferences" map to each other...)

While I am excited about all this, they do need to leave, in my opinion, the usual menu bar accessible and visible. The reason is simple: during the initial learning phase of an application, you don't even know what's possible. You need some way to explore the available commands, see what the app can do, and experiment. Only once you're somewhat familiar with the application does it make sense to quickly invoke commands with the keyboard.

Mozilla is working on something that will simplify the login process. It doesn't sound to me as though it is as advanced as the ideas you've discussed, but here's the link anyway.

Mozilla is building an open standards-based API for apps that allow app developers to develop once and run anywhere. Have a look here for a preview. We'll be investing considerably more in this project in the coming year. See more here https://apps.mozillalabs.com/

And no, Mozilla would absolutely not sacrifice something fundamental to our Mission for revenue. See more here http://www.mozilla.org/about/mission.html

I came here to say the same thing. Also, Google and Mozilla are experimenting with making such functionality available to webapps as Web Intents / Web Activities http://webintents.org/ http://mozillalabs.com/blog/2011/07/web-apps-update-experiments-in-web-activities-app-discovery/ I hope Microsoft will join the effort rather than making a separate system.

linked from TFA: Mozilla's take
linked from Mozilla's take: blog post by someone at Google who talked about it last year

I'm not sure I understand. Prism still exists, and it sounds like what you want, so I don't understand why you say it "turned into Chromeless."

I think he meant this announcement, that focus is shifting from Prism to Chromeless.

But, OP is wrong about "[Chromeless] seems to have died [Note: last update was May 31]" - yes, the last blogpost was May 31, but the last source code commit on github was less than a month ago. That doesn't sound 'dead' to me.

So Chromeless sounds like the way to go here, for what OP is looking for.

I'm not sure I understand. Prism still exists, and it sounds like what you want, so I don't understand why you say it "turned into Chromeless."

I think he meant this announcement, that focus is shifting from Prism to Chromeless.

But, OP is wrong about "[Chromeless] seems to have died [Note: last update was May 31]" - yes, the last blogpost was May 31, but the last source code commit on github was less than a month ago. That doesn't sound 'dead' to me.

So Chromeless sounds like the way to go here, for what OP is looking for.

Follow the links on the page you provided, and you'll see that Prism isn't supported past Firefox 3.6.*. Also, Mozilla themselves said that Prism is now Chromeless.

I'm not sure I understand. Prism still exists, and it sounds like what you want, so I don't understand why you say it "turned into Chromeless."

It's also very easy to embed Internet Explorer in things. A friend of mine once "wrote a Web browser" in Macromedia Director using about six lines of code.

They could, yes, and that's what JetPack is about. Unfortunately, while that's 1.0 the API is still rather inadequate, and they're way behind Chrome on it. Essentially, if you are okay with being limited an uninnovative, you're better off going for Chrome instead.

Chrome uses an extension API to help ensure that extensions work from one version to the next. They also have an updating mechanism that ensures nearly all users have updated to the latest version of Chrome within a week of final release. Firefox has neither of these, so extensions can easily break from one version to the next, and it could be months until most Firefox users update to the latest version. Mozilla should have ensured their updating mechanism worked quickly and most popular extensions used Jetpack before they switched to a rapid release schedule like Chrome has.

I thought Chromeless, which evolved from Prism, was the answer to that...

I thought Chromeless, which evolved from Prism, was the answer to that...

just two weeks ago. Webian Shell on top of Linux sounds a lot like Chrome OS to me...

I'm the author of the guest blog post. I have some clarifications that should clear things up a lot.

First, I'm just a member of the large community of Firefox users. I do not work for Mozilla (though that would be awesome), and I do not speak for Mozilla. As far as I know, no one within Mozilla is working on implementing any of my ideas at the moment. I simply had a concept and was offered the amazing opportunity to write some guest blog posts. The linked post is Part 1. Part 2 is coming.

Second, contrary to the article summary and to the many comments from people who clearly did not read the post, I am not proposing to hide the location. The location will be completely visible at the top of each page, with even more information. As far as I can tell, there is nothing that the location bar can do that is not possible in my concept.

Finally, the arguments behind each step are available in much more detail on the Mozilla Wiki. That should answer many questions.

if you want to contribute to the discussion in a substantive manner, please first read the article and then go to the discussion page. I've already responded to a number of excellent comments there. Also, if anyone is interested in helping me implement some of these ideas, please let me know!

David

What's next, the back button?

Yep.

From http://mozillalabs.com/conceptseries/2011/05/24/community-concepts-ubiquitous-firefox-part-1-how-do-you-design-a-debris-less-browser/

Next time, I want to revisit the Back and Forward buttons more deeply, to rethink the way they’ve functioned since their inception

Well I know it's cheating to RTFA, but most of the complaints in the comments right now are totally missing the mark, since their worries are addressed in the actual blog post. There's plenty enough that's wrong with this idea without imagining problems that are not there or haven't been addressed in this idea. (And it is just an off-the-wall idea right now.)
Let me address some complaints: 1. Why hide the URL bar, it gives useful information! The proposal actually still keeps all the URL information. However instead of it always sitting at the top of the browser chrome, it's attached to the webpage, and scrolls up/down with it so that you can scroll it out of the way when you want. There is some logic to this: you normally want to look at the URL when you first land on a page. After that you don't need it as much. (Yes, there are exceptions.) The proposal is in fact to add more information to keep the user informed. (A possible downside is information overload.)
2. Why is Mozilla copying Google? From what I can tell this isn't inspired from Google, other than in the sense that there is a general trend to reduce chrome (and not just in browsers). The Google proposal is to auto-hide the URL bar, and have it popup when needed. This proposal is to conceptually attach the url to the page rather than to the browser chrome.
3. How am I going to enter new URLs without the URL bar? The proposal is that you will either edit the URL that is at the top of the current page, or use a "browse" command where you'll be able to type or paste an URL.

Now, having addressed (partially) those immediate concerns, let's ask whether this is a good idea or not. Personally, I'm in favor of at least designing and testing new, crazy UI ideas. It's the only way that we can discover new and better ways to interact with out computer. So I'm supportive of having a discussion, and I don't think changing the URL bar should be off the table. That having been said, the proposal has a number of problems:
1. It heavily draws upon Jef Raskin's design rule of "there should be only one way to accomplish a certain atomic task". The idea is that by having only way, good, way to do something, users can train and habitualize and accomplish the task faster and without thinking. It's true that psych research has shown that having options (including different ways to do the same thing) subtly slows down a person's response time and thus can jar their thought processes. However I haven't seen any conclusive research showing that this is significant enough to warrant having a "only one way" rule--since it denies (for instance) power users the ability to learn keyboard shortcuts, can make it more difficult for accessibility or even just for people of various abilities (some people can't type well but can click on icons well enough). The design in the blog post favors a natural-language text entry system (basically the Ubiquity system that exists for Firefox). Personally, I quite like that mode of controlling a computer, but I suspect the vast majority of people would view this kind of command-entry (much like a commandline, though somewhat more forgiving) as being very intimidating. Overall, I'm not convinced that having only "one way" to control the interface makes sense.

2. The author takes it as a given that we should aim to reduce application chrome. Again, I personally agree with this from both an aesthetic standpoint, and from a usability standpoint. But then again, that's because I'm happy spending the time to memorize keyboard shortcuts and other tricks (e.g. instaling mouse gestures) so that I can remove the chrome and concentrate on the content. But, again, I don't think this really applies to everyone.

Well I know it's cheating to RTFA, but most of the complaints in the comments right now are totally missing the mark, since their worries are addressed in the actual blog post. There's plenty enough that's wrong with this idea without imagining problems that are not there or haven't been addressed in this idea. (And it is just an off-the-wall idea right now.)
Let me address some complaints: 1. Why hide the URL bar, it gives useful information! The proposal actually still keeps all the URL information. However instead of it always sitting at the top of the browser chrome, it's attached to the webpage, and scrolls up/down with it so that you can scroll it out of the way when you want. There is some logic to this: you normally want to look at the URL when you first land on a page. After that you don't need it as much. (Yes, there are exceptions.) The proposal is in fact to add more information to keep the user informed. (A possible downside is information overload.)
2. Why is Mozilla copying Google? From what I can tell this isn't inspired from Google, other than in the sense that there is a general trend to reduce chrome (and not just in browsers). The Google proposal is to auto-hide the URL bar, and have it popup when needed. This proposal is to conceptually attach the url to the page rather than to the browser chrome.
3. How am I going to enter new URLs without the URL bar? The proposal is that you will either edit the URL that is at the top of the current page, or use a "browse" command where you'll be able to type or paste an URL.

Now, having addressed (partially) those immediate concerns, let's ask whether this is a good idea or not. Personally, I'm in favor of at least designing and testing new, crazy UI ideas. It's the only way that we can discover new and better ways to interact with out computer. So I'm supportive of having a discussion, and I don't think changing the URL bar should be off the table. That having been said, the proposal has a number of problems:
1. It heavily draws upon Jef Raskin's design rule of "there should be only one way to accomplish a certain atomic task". The idea is that by having only way, good, way to do something, users can train and habitualize and accomplish the task faster and without thinking. It's true that psych research has shown that having options (including different ways to do the same thing) subtly slows down a person's response time and thus can jar their thought processes. However I haven't seen any conclusive research showing that this is significant enough to warrant having a "only one way" rule--since it denies (for instance) power users the ability to learn keyboard shortcuts, can make it more difficult for accessibility or even just for people of various abilities (some people can't type well but can click on icons well enough). The design in the blog post favors a natural-language text entry system (basically the Ubiquity system that exists for Firefox). Personally, I quite like that mode of controlling a computer, but I suspect the vast majority of people would view this kind of command-entry (much like a commandline, though somewhat more forgiving) as being very intimidating. Overall, I'm not convinced that having only "one way" to control the interface makes sense.

2. The author takes it as a given that we should aim to reduce application chrome. Again, I personally agree with this from both an aesthetic standpoint, and from a usability standpoint. But then again, that's because I'm happy spending the time to memorize keyboard shortcuts and other tricks (e.g. instaling mouse gestures) so that I can remove the chrome and concentrate on the content. But, again, I don't think this really applies to everyone.

There's no way of knowing how much memory each extension is using. Extension code is thrown into a big JavaScript/XUL soup with shared data structures. With the new Jetpack API it may be possible to determine how much memory and CPU each extension is using. Even if some users do need to find which extension is causing memory usage problems, there is a list of the extensions that cause the most problems.

Mozilla are there already.

http://mozillalabs.com/blog/2011/04/protecting-users-from-an-age-old-threat/

Jetpack should make extension compatibility a much better experience as it gains traction. https://jetpack.mozillalabs.com/

You should use the new JetPack API so you don't need to update your plugin every time a new version of Firefox is released. Better yet, release a plugin that tells all the other plugin developers to use JetPack.

Mozilla already has a Labs project that goes even further by hiding ALL the UI and showing it only on demand. It's called Home Dash.

Ohh, spoke to soon, freeciv was submitted: https://gaming.mozillalabs.com/games/

Why are slashdot stories linking to web sites that aren't directly related to the story? This story would have been better linked to the blog post at Mozilla Labs: https://mozillalabs.com/blog/2011/02/prism-is-now-chromeless/

They actually sorta have a project for that: https://mozillalabs.com/chromeless/

Click the first link of TFS and you will learn:
The Grand Prize winner was James Fiedler
There were two Finalists.
There were five Honorable Mentions.

You may be interested in https://jetpack.mozillalabs.com/ which is precisely such a stable API.

Of course, being stable makes it more limited. It can't totally rejigger your browser window, say; if it could it would break when the design of that window changed, right?

Now will extension authors write to the stable API or continue to do the Windows equivalent of writing custom drivers as part of their app? Who knows.

That just sounds like this:
https://apps.mozillalabs.com/

Esp with items like Prism: http://prism.mozillalabs.com/ and the Prism Plugin. Add in Firefox 4 and now you can have a webapp office suite that downloads to an icon, that can access your local files AND provide a web portal for hosting documents if needed.

Somebody needs to point this guy to Mozilla Labs and tell him to join the community and start working on his own dreams instead of proposing/forcing them on the community.

This is my biggest complaint with many Open Source "lusers" and it happens all the time. I often see bug reports which look like, "Please fix ABC or add new feature XYZ ASAP. It shouldn't be too hard to fix. This ticket is priority important because I need this feature yesterday." People seem to think that Open Source means that programmers will magically write the software they need for free.

They don't know their history. It only took Mozilla nearly five years to release something that resembled a better web browser, and even then the early releases were slow and sometime buggy.

The good news was that after five years of no competition, Internet Explorer's team had been cut to the bone and IE was so stagnant that it took a few years before Microsoft could effectively restart the team. Somehow I don't think they'll let that happen to their office suite, as that's where they make most of their money (as opposed to IE which was a give-away product released only for competitive purposes).

Seriously? Somebody needs to point this guy to Mozilla Labs and tell him to join the community and start working on his own dreams instead of proposing/forcing them on the community.
 

Maybe you should point him to it instead of wishing someone else would do it.

Somebody needs to point this guy to Mozilla Labs and tell him to join the community and start working on his own dreams instead of proposing/forcing them on the community.

This is my biggest complaint with many Open Source "lusers" and it happens all the time. I often see bug reports which look like, "Please fix ABC or add new feature XYZ ASAP. It shouldn't be too hard to fix. This ticket is priority important because I need this feature yesterday." People seem to think that Open Source means that programmers will magically write the software they need for free.

"Imagine if Mozilla decided tomorrow to build an office suite. Imagine all those ideas. Imagine how brilliant that could be. Just imagine. Now imagine Firefox 4. Honestly, which one of those are you most excited by?"

Seriously? Somebody needs to point this guy to Mozilla Labs and tell him to join the community and start working on his own dreams instead of proposing/forcing them on the community.

I mean, PCPro has done a really great job of bringing us news stories before but they've kind of fallen by the wayside and become irrelevant. Maybe if they switched and stuck their nose in something else it would benefit me a lot more so I think they should do that despite the obvious potential of failure. I mean, maybe they should start publishing cures for cancer and AIDS? Imagine all those ideas like a news site that actually pays the reader money. Imagine how brilliant that could be. Just imagine. Now imagine tomorrow's news article where they tell me the top ten things that are a threat to my computer. Honestly, which one of those are you most excited by?

Oh, look at me, I'm the magical man from imaginationland and I live in imagined houses made of fantasy bricks and -- look over there -- it's John Lennon using Firefox's new Office suite!

I like how some talking heads imagine that software "just happens." It doesn't take sleepless nights and thousands of weighty e-mails and collaboration ... you just have to say or think something and suddenly it exists.

I also like how Mozilla can afford to spread themselves thin now that they have lost the browser war. If people had his attitude, we'd only see one leader in any field because everyone else gives up and doesn't try to regain the lead.

Nothing but wishful spurious logic.

Just speaking of inconsistencies, the text links at the top of http://www.mozillalabs.com/gaming/ (which use a web font - Museo Sans) look different in Firefox and Chrome, while on https://gaming.mozillalabs.com/ the red circles with "Read blog", "Follow" are rendered incorrectly by Chrome (latest DEV build). What's not to love?

Just speaking of inconsistencies, the text links at the top of http://www.mozillalabs.com/gaming/ (which use a web font - Museo Sans) look different in Firefox and Chrome, while on https://gaming.mozillalabs.com/ the red circles with "Read blog", "Follow" are rendered incorrectly by Chrome (latest DEV build). What's not to love?

Now here's what would be awesome: If I could share a window in my text editor / IDE with someone else on the planet, edit a piece of source together in real time, and still be able to save and compile directly from within the software. Oh, wait...

DancesWithBlowTorch, keep an eye on Mozilla's Bespin. I've used the very basic skeleton project they had and think they're on track but it's coming along and will hopefully firm up once HTML5 support and standards become common place. I don't know how fluid it will become with real time updates but imagine editing your code anytime from any browser that is HTML 5 compliant and your collaborators seeing that. Not sure how many languages they plan on incorporating but when it's done, your source will exist and be compiled in the cloud. Maybe not ideal for a business but for open source collaboration ... really neat!

This is part of the reason to switch to the new Jetpack extension API from the old JavaScript code soup extension model.

From the Jetpack FAQ:

The Jetpack SDK lets you write add-ons that run in Firefox, Firefox Mobile, and as stand-alone applications using only the familiar technologies of the Web (HTML, Javascript, and CSS). Your add-ons will be faster to code and debug, easier to maintain, and more stable due to the extensible code library and the instant save-refresh development cycle. Your add-ons will also enjoy a stronger, more understandable security model that will keep your users safe.

Depends on what they want to test. Here is a list so far: https://testpilot.mozillalabs.com/testcases/

Just using Mozilla Test Piliot add-on.

Regarding IDE, there's Bespin which runs on ChromeOS.

not quite there yet, but soonish: https://bespin.mozillalabs.com/

> Will it require something on my desktop that then sends all the information from my
> browser to their servers?

Yes (though note https://wiki.mozilla.org/Labs/Weave/Crypto for details; the only data the server sees is an encrypted blob).

> Does firefox do that currently now?

Only if you install the relevant extension. See https://mozillalabs.com/sync/

I hope windowing systems die soon.

We all have our complaints about windowing systems. It does indeed seem like we spend a fair amount of time just managing the windows (moving, resizing, etc.) rather than working. Like you, I'm pretty convinced that there has to be a better design out there. But I don't think it's the right strategy to throw-out windowing systems altogether, without a viable alternative to actually push towards. Despite all their warts, our modern GUIs are by now highly tuned and in fact do help us be productive.

There has to be a better design than a metaphor to desks and file cabinets...

I think our modern desktop metaphor isn't really mimicking desks and file cabinets in any meaningful way. Sure, the same terms are applied ("desktop", "folder", "file", etc.), but in reality the computer-objects bear little resemblance to the real-world objects. (You can't infinitely nest folders in the real world!) I think our GUI metaphors have abandoned any real-world resemblance that was slowing them down. (E.g. you can't arbitrarily resize a real-world sheet of paper on the fly, but it's easy to resize a GUI.)

I'm not sure what the answer is (mostly just thinking out loud, here), but I think our time would be better spent refining the modern GUI, rather than throwing it all away and hoping that something fantastically better fills the void. Some ideas that spring to mind:
1. Windows in a GUI are useful (e.g. to read from one and type into another) but managing all the windows is as much fun as shuffling paper on a real desk. What would help is far smarter layout algorithms. When a new window appears, its size and position should "make sense". For instance it should be in some way proportional to the amount of text within it. It should try to appear in areas that will not obscure existing content. A given document should re-open to the same position on screen as the last time you had it open (thereby taking advantage of human visual memory and habit-forming procedures). A GUI that shuffled all the windows around on you would probably be more annoying than helpful. But some amount of predictive behavior would be nice (e.g. tossing a window towards one edge of the screen could dock it there cleanly.)
2. GUIs should let users easily define tasks rather than forcing them to manually open all the windows/documents associated with a given workflow. So when I open the "banking" task, my financial spreadsheets should open (and appear with the size/position I always set them to), my Firefox window should appear in the right place with the right websites all open, my calculator app should pop open in the upper-right-hand-corner, and so on... It should be easier for users to define sets of tasks and have those states reappear when required. This all boils down to: the size, position, and state of all the windows on-screen actually conveys useful information to the user! Don't throw that information away!
3. Each app should have a hidden backend database where every command and help topic (with appropriate index terms and tags/keywords and synonyms) is stored. If you can't remember where the button or menu item for a given task is, it should be trivial to type that into a persistent "help/do-stuff" bar and have the option simply appear, ready to be clicked/invoked. For apps with tons of options (MS Word, Photoshop, etc.) this would make it trivial to find the option you want. (Just type "red eye correction" or "make sentence all caps" or whatever.) If done properly, this would also allow users to interact with applications in a faster text-command mode (anyone who has used Firefox's Ubiquity will know what I'm talking about.)

These are just the ideas that have occurred to me (repeatedly) and may not be the best ideas out there. Overall my point is that I agree we need better GUI-interaction styles... but that I think we can use the existing windowing systems as good starting points for further refinement.

Mozilla has used an extension called Test Pilot to study user behavior. One study focused on usage of the menu bar. The results show a kind of power law in menu item usage. This suggests that you can probably ditch most of the menu items, and provide alternative methods to access the top used functions. I think this is broadly what they are going for in the proposed 4.0 UI redesign.

Mozilla has used an extension called Test Pilot to study user behavior. One study focused on usage of the menu bar. The results show a kind of power law in menu item usage. This suggests that you can probably ditch most of the menu items, and provide alternative methods to access the top used functions. I think this is broadly what they are going for in the proposed 4.0 UI redesign.

Mozilla has used an extension called Test Pilot to study user behavior. One study focused on usage of the menu bar. The results show a kind of power law in menu item usage. This suggests that you can probably ditch most of the menu items, and provide alternative methods to access the top used functions. I think this is broadly what they are going for in the proposed 4.0 UI redesign.

You laugh, but Mozilla Raindrop, the latest project by the Thunderbird devs, uses CouchDB. No April fools here.