Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.misc > #23735 > unrolled thread

Mozilla's new vision

Back to article view | Back to comp.misc

Contents

  Mozilla's new vision Ben Collver <bencollver@tilde.pink> - 2023-12-30 17:34 +0000
    Re: Mozilla's new vision Anton Shepelev <anton.txt@gmail.moc> - 2023-12-30 21:16 +0300
      Re: Mozilla's new vision Andy Burns <usenet@andyburns.uk> - 2023-12-30 19:24 +0000
        Re: Mozilla's new vision not@telling.you.invalid (Computer Nerd Kev) - 2023-12-31 07:05 +1000
          Re: Mozilla's new vision Andy Burns <usenet@andyburns.uk> - 2023-12-31 09:40 +0000
      Re: Mozilla's new vision Ben Collver <bencollver@tilde.pink> - 2023-12-30 22:12 +0000
        Re: Mozilla's new vision kludge@panix.com (Scott Dorsey) - 2023-12-31 00:50 +0000
    Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2023-12-30 17:48 -0300
      Re: Mozilla's new vision not@telling.you.invalid (Computer Nerd Kev) - 2023-12-31 07:38 +1000
        Re: Mozilla's new vision Andy Burns <usenet@andyburns.uk> - 2023-12-31 09:34 +0000
          Re: Mozilla's new vision not@telling.you.invalid (Computer Nerd Kev) - 2024-01-01 07:01 +1000
      Re: Mozilla's new vision yeti <yeti@tilde.institute> - 2023-12-31 03:12 +0042
      Re: Mozilla's new vision yeti <yeti@tilde.institute> - 2023-12-31 03:13 +0042
        Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2023-12-31 00:37 -0300
          Re: Mozilla's new vision immibis <news@immibis.com> - 2024-01-02 00:56 +0100
            Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-02 01:07 -0300
              Re: Mozilla's new vision immibis <news@immibis.com> - 2024-01-02 18:30 +0100
                Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-03 03:05 -0300
                  Re: Mozilla's new vision yeti <yeti@tilde.institute> - 2024-01-03 09:10 +0042
                    Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-03 16:22 -0300
                      Re: Mozilla's new vision yeti <yeti@tilde.institute> - 2024-01-03 21:56 +0042
                      Re: Mozilla's new vision immibis <news@immibis.com> - 2024-01-06 04:17 +0100
                        Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-06 01:32 -0300
              Re: Mozilla's new vision Mike Spencer <mds@bogus.nodomain.nowhere> - 2024-01-03 01:56 -0400
                Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-03 16:15 -0300
      Re: Mozilla's new vision Marco Moock <mm+usenet-es@dorfdsl.de> - 2023-12-31 10:43 +0100
        Re: Mozilla's new vision Theo <theom+news@chiark.greenend.org.uk> - 2023-12-31 10:55 +0000
          Re: Mozilla's new vision Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-01-01 10:13 +0100
            Re: Mozilla's new vision Mike Spencer <mds@bogus.nodomain.nowhere> - 2024-01-01 17:11 -0400
              Re: Mozilla's new vision Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-01-02 08:34 +0100
            Re: Mozilla's new vision Theo <theom+news@chiark.greenend.org.uk> - 2024-01-03 12:00 +0000
              Re: Mozilla's new vision Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-01-03 14:43 +0100
                Re: Mozilla's new vision Theo <theom+news@chiark.greenend.org.uk> - 2024-01-03 17:48 +0000
                  Re: Mozilla's new vision Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-01-03 20:45 +0100
      Re: Mozilla's new vision Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-12-31 12:10 +0000
        Re: Mozilla's new vision Andy Burns <usenet@andyburns.uk> - 2023-12-31 13:36 +0000
          Re: Mozilla's new vision Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-12-31 19:28 +0000
        Re: Mozilla's new vision kludge@panix.com (Scott Dorsey) - 2023-12-31 15:10 +0000
      Re: Mozilla's new vision cr0c0d1le <cr0c0d1le.ewlkg@8shield.net> - 2024-01-01 13:41 -0500
        Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-02 01:07 -0300
        Re: Mozilla's new vision Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-01-02 08:36 +0100
          Re: Mozilla's new vision candycanearter07 <no@thanks.net> - 2024-01-02 17:35 -0600
            Re: Mozilla's new vision immibis <news@immibis.com> - 2024-01-06 03:47 +0100
      Re: Mozilla's new vision immibis <news@immibis.com> - 2024-01-02 00:48 +0100
        Re: Mozilla's new vision Marco Moock <mm+usenet-es@dorfdsl.de> - 2024-01-02 08:37 +0100
          Re: Mozilla's new vision Andy Burns <usenet@andyburns.uk> - 2024-01-02 09:01 +0000
            Re: Mozilla's new vision immibis <news@immibis.com> - 2024-01-02 18:28 +0100
            Re: Mozilla's new vision not@telling.you.invalid (Computer Nerd Kev) - 2024-01-03 06:48 +1000
            Re: Mozilla's new vision Andreas Kempe <kempe@lysator.liu.se> - 2024-01-03 01:19 +0000
              Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-03 03:25 -0300
              Re: Mozilla's new vision immibis <news@immibis.com> - 2024-01-06 04:33 +0100
                Re: Mozilla's new vision Julieta Shem <jshem@yaxenu.org> - 2024-01-06 01:34 -0300

Page 1 of 3  [1] 2 3  Next page →

#23735 — Mozilla's new vision

From JWZ's blog:

Earlier this year, Mozilla laid out their vision for the future of their
organization -- and it did not include Firefox. The focus for the future
of Mozilla -- according to Mozilla -- is primarily based around
Artificial Intelligence services.

In fact, Mozilla leadership stated, quite plainly, that they intend to
take Mozilla "in a different direction."

https://blog.mozilla.org/en/mozilla/mark-surman-mozilla-25-years/
   
When you consider the goals of Mozilla... the decreasing Firefox
marketshare is no longer much of a concern. In fact, moving revenue away
from Firefox, while investing in A.I. systems (and other subscription
services) becomes the primary goal. [...]

[toc] | [next] | [standalone]

#23737

Ben Collver:

> In fact, moving revenue away from Firefox, while investing
> in A.I. systems (and other subscription services) becomes
> the primary goal.

As one clueless about modern economy, I wonder what kind of
revenue can Mozilla be drawing from a web browser that is
free as in beer.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

[toc] | [prev] | [next] | [standalone]

#23739

Anton Shepelev wrote:

> Ben Collver:
> 
>> moving revenue away from Firefox, while investing
>> in A.I. systems (and other subscription services) becomes
>> the primary goal.

Oh dear ...

> As one clueless about modern economy, I wonder what kind of
> revenue can Mozilla be drawing from a web browser that is
> free as in beer.

Until now, they've been quite successful in tapping Google for hundreds 
of $millions per year, but who knows for how much longer?  I presume the 
side-lines such as Pocket or VPNs are pocket change in comparison ...

[toc] | [prev] | [next] | [standalone]

#23741

Andy Burns <usenet@andyburns.uk> wrote:
> Anton Shepelev wrote:
>> As one clueless about modern economy, I wonder what kind of
>> revenue can Mozilla be drawing from a web browser that is
>> free as in beer.
> 
> Until now, they've been quite successful in tapping Google for hundreds 
> of $millions per year, but who knows for how much longer?

Yes, unfortunately it sounds like they're getting prepared to drop
Firefox like a stone as soon as Google stops sending them cheques.

> I presume the side-lines such as Pocket or VPNs are pocket change
> in comparison ...

This more recent Blog post appears to be an example of one of the
new Mozilla projects, an AI website builder:
https://blog.mozilla.org/en/mozilla/introducing-solo-ai-website-builder/

They're going from offering a product with only one real
competitor, to products where the market is as crowded as could
possibly be. It seems a bit desperate.

For Firefox, this blog post looks ominous too:
"Why we're renaming 'Firefox accounts' to 'Mozilla accounts'"
https://blog.mozilla.org/en/mozilla/firefox-accounts-transition-mozilla-accounts/

-- 
__          __
#_ < |\| |< _#  | Note: I won't see posts made from Google Groups |

[toc] | [prev] | [next] | [standalone]

#23750

Computer Nerd Kev wrote:

> For Firefox, this blog post looks ominous too:
> "Why we're renaming 'Firefox accounts' to 'Mozilla accounts'"
> https://blog.mozilla.org/en/mozilla/firefox-accounts-transition-mozilla-accounts/

I don't see a thunderbird icon in that list (yes, I know MZLA is at 
least arms-length from moz://a)

[toc] | [prev] | [next] | [standalone]

#23743

On 2023-12-30, Anton Shepelev <anton.txt@gmail.moc> wrote:
> Ben Collver:
>> In fact, moving revenue away from Firefox, while investing
>> in A.I. systems (and other subscription services) becomes
>> the primary goal.
>
> As one clueless about modern economy, I wonder what kind of
> revenue can Mozilla be drawing from a web browser that is
> free as in beer.

There's the busking model: annoy users into giving you money, like
public radio and Wikipedia habitually do.

[toc] | [prev] | [next] | [standalone]

#23745

On 2023-12-30, Anton Shepelev <anton.txt@gmail.moc> wrote:
>
> As one clueless about modern economy, I wonder what kind of
> revenue can Mozilla be drawing from a web browser that is
> free as in beer.

Sure, they lose money on the product but they make it up in volume!
It worked for Crazy Eddie!
--scott

-- 
"C'est un Nagra. C'est suisse, et tres, tres precis."

[toc] | [prev] | [next] | [standalone]

#23740

Ben Collver <bencollver@tilde.pink> writes:

> From JWZ's blog:
>
> Earlier this year, Mozilla laid out their vision for the future of their
> organization -- and it did not include Firefox. The focus for the future
> of Mozilla -- according to Mozilla -- is primarily based around
> Artificial Intelligence services.
>
> In fact, Mozilla leadership stated, quite plainly, that they intend to
> take Mozilla "in a different direction."
>
> https://blog.mozilla.org/en/mozilla/mark-surman-mozilla-25-years/
>    
> When you consider the goals of Mozilla... the decreasing Firefox
> marketshare is no longer much of a concern. In fact, moving revenue away
> from Firefox, while investing in A.I. systems (and other subscription
> services) becomes the primary goal. [...]

Without a Free Software browser, the web will be completely dominated by
corporate actors.  Intelligent people will leave and look for
alternatives.  We could go back to gopher-like services.  In fact, see
the gemini protocol.

The web is not control-resistant because it's difficult to build a
browser.  So difficult that you can only compete if you're a big group.
So there is no diversity in the offer.  Without diversity, its survival
is greatly threatened.

[toc] | [prev] | [next] | [standalone]

#23742

Julieta Shem <jshem@yaxenu.org> wrote:
> Without a Free Software browser, the web will be completely dominated by
> corporate actors.  Intelligent people will leave and look for
> alternatives.  We could go back to gopher-like services.  In fact, see
> the gemini protocol.

I read the blog post in Dillo, and although the developer of that
browser has disappeared, there are forks, and similar projects like
Links and (less active) Netsurf.

Gopher and Gemini don't need to replace the web so that people can
keep using "free software", websites just need to use the features
of HTML that allow them to be compatible with that software. For
the web pages that aren't usable in those alternative browsers,
it's a more reasonable proposition for those website developers to
implement Javascript-free fall-back solutions than have them switch
to Gopher or Gemini. In fact many used to do that once, only they
stopped.

> The web is not control-resistant because it's difficult to build a
> browser.  So difficult that you can only compete if you're a big group.
> So there is no diversity in the offer.  Without diversity, its survival
> is greatly threatened.

As standard go, the Web still fully supports building websites
compatible with all browsers. There's a ton of extremely
complicated stuff that's been added over the years, but it's
optional. The trouble is that it's not treated as optional from
the client-side by website developers, only as options to pick
from on their side, with the assumption that if an option is
supported in Chrome then it's supported by the one client that
everyone actually uses and therefore alternative methods don't
matter.

Gopher and Gemini could go exactly the same way if people with the
same attitude did adopt them to build a complete Web alternative.
It's not a standards problem, it's a culture problem.

-- 
__          __
#_ < |\| |< _#  | Note: I won't see posts made from Google Groups |

[toc] | [prev] | [next] | [standalone]

#23749

Computer Nerd Kev wrote:

> For the web pages that aren't usable in those alternative browsers, 
> it's a more reasonable proposition for those website developers to 
> implement Javascript-free fall-back solutions than have them switch 
> to Gopher or Gemini. In fact many used to do that once, only they 
> stopped.
They stopped because they didn't like effectively having to develop the 
site twice, and maintain both modes

Seems a *lot* of effort has gone into competing client-side frameworks 
to make websites interact like fat-client programs used to, maybe the 
effort should have been server-side that generates client-side that 
works reliably with/without javascript?

I must admit, because there are *so* many of these frameworks being 
produced, I don't have time to look at them, to see if any are doing 
that, but based on how gracelessly websites fail without javascript now, 
I'm guessing not ...

[toc] | [prev] | [next] | [standalone]

#23757

Andy Burns <usenet@andyburns.uk> wrote:
> Computer Nerd Kev wrote:
>> For the web pages that aren't usable in those alternative browsers, 
>> it's a more reasonable proposition for those website developers to 
>> implement Javascript-free fall-back solutions than have them switch 
>> to Gopher or Gemini. In fact many used to do that once, only they 
>> stopped.
> They stopped because they didn't like effectively having to develop the 
> site twice, and maintain both modes
> 
> Seems a *lot* of effort has gone into competing client-side frameworks 
> to make websites interact like fat-client programs used to, maybe the 
> effort should have been server-side that generates client-side that 
> works reliably with/without javascript?

There might be some technical advantage for the website operator
that can come from doing more data processing at the client side
to reduce server load, although it would often come at the expense
of sending more data to the client and more exposure to security
vulnerabilities. But I suspect it's mainly about making things look
like someone's idea of pretty, in which case a Javascript-optional
framework might be used. I don't know what would cause such a thing
to be written and adopted now though, wonderful as it would be.

-- 
__          __
#_ < |\| |< _#  | Note: I won't see posts made from Google Groups |

[toc] | [prev] | [next] | [standalone]

#23746

Julieta Shem <jshem@yaxenu.org> writes:

> Without a Free Software browser, the web will be completely dominated by
> corporate actors.  Intelligent people will leave and look for
> alternatives.  We could go back to gopher-like services.  In fact, see
> the gemini protocol.

Why?

If you can self-host gemini or gopher, you can do that with http too.
Noone forces you to use QIC, CSS or JS.  A reasonable subset of today's
overfeatured http/html still can and will play a role.

The problem is not what to use when writing for friends and reading that
with lynx, w3m, netsurf, dillo, emacs/eww, elinks, ...

The problem is that some things in daily life force us to use browsers
we would like not to touch at all for some services we cannot avoid.
That's the part that needs a massive revolt and there neither gopher nor
gemini will be the solution.

-- 
"Wir Europäer sind dafür bekannt, dass wir gerne Dinge verbieten. Das
Prinzip der Datensparsamkeit, wie wir es vor vielen Jahren hatten, kann
heute nicht die generelle Leitschnur sein für die Entwicklung neuer
Produkte." - Angela Merkel beim nationalen IT-Gipfel 2016 in Saarbrücken

[toc] | [prev] | [next] | [standalone]

#23747

Julieta Shem <jshem@yaxenu.org> writes:

> Without a Free Software browser, the web will be completely dominated by
> corporate actors.  Intelligent people will leave and look for
> alternatives.  We could go back to gopher-like services.  In fact, see
> the gemini protocol.

Why?

If you can self-host gemini or gopher, you can do that with http too.
Noone forces you to use QUIC, CSS or JS.  A reasonable subset of today's
overfeatured http/html still can and will play a role.

The problem is not what to use when writing for friends and reading that
with lynx, w3m, netsurf, dillo, emacs/eww, elinks, ...

The problem is that some things in daily life force us to use browsers
we would like not to touch at all for some services we cannot avoid.
That's the part that needs a massive revolt and there neither gopher nor
gemini will be the solution.

-- 
"Wir Europäer sind dafür bekannt, dass wir gerne Dinge verbieten. Das
Prinzip der Datensparsamkeit, wie wir es vor vielen Jahren hatten, kann
heute nicht die generelle Leitschnur sein für die Entwicklung neuer
Produkte." - Angela Merkel beim nationalen IT-Gipfel 2016 in Saarbrücken

[toc] | [prev] | [next] | [standalone]

#23748

yeti <yeti@tilde.institute> writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> Without a Free Software browser, the web will be completely dominated by
>> corporate actors.  Intelligent people will leave and look for
>> alternatives.  We could go back to gopher-like services.  In fact, see
>> the gemini protocol.
>
> Why?

I don't know, but it's what happens right now.  All browser vendors are
major players, unlike NNTP servers, which are so simple that a single
person can implement in a weekend, so you find lots of alternatives.
Not so with browsers.

> If you can self-host gemini or gopher, you can do that with http too.

Of course.

> Noone forces you to use QUIC, CSS or JS.  A reasonable subset of
> today's overfeatured http/html still can and will play a role.

When we talk about browsers, we are not necessarily talking about the
protocols they speak.

> The problem is that some things in daily life force us to use browsers
> we would like not to touch at all for some services we cannot avoid.

Precisely.

You can always walk in other people's land, but as soon as you upset the
owners they kick you out.  It's like having freedom until your boss says
you don't.

> That's the part that needs a massive revolt and there neither gopher
> nor gemini will be the solution.

The solution is a web that's simple.  The protocol seems to be doing
well enough, but the browser is a total disaster.  If only a handful of
people can build it, it's a total disaster.  Without diversity, there's
no resilience.

[toc] | [prev] | [next] | [standalone]

#23770

On 12/31/23 04:37, Julieta Shem wrote:
> 
> I don't know, but it's what happens right now.  All browser vendors are
> major players, unlike NNTP servers, which are so simple that a single
> person can implement in a weekend, so you find lots of alternatives.
> Not so with browsers.
> 

Anyone can write a web *server* or mail *server* or news *server* in a 
weekend, but there's a lot of complexity that passes through web and 
mail servers from end-to-end, which the server doesn't have to process.

I wrote a Minecraft server from scratch once; I had to pass messages 
from one player to another saying "this player broke this block", but I 
never had to check whether the player could actually reach the block, 
because I trusted the client for that. (The real Minecraft server 
includes a lot more game-logic code and doesn't trust clients as much.)

But if I wanted to write a Minecraft *client*, I'd have to have all the 
game logic. I'd have to know the exact shape of every block, so I could 
know at which coordinates players could stand, and I could know which 
parts of which blocks they could reach through and see through without 
cheating, and I'd have to know exactly how long each block took to mine 
and how to calculate it according to the player's equipped mining tool.

The same problem applies to browsers and email readers. Conveying bytes 
from A to B is a solved problem. Making sure those bytes mean what the 
sender intended is much more difficult.

News sidesteps the problem for now by only being plaintext, which it can 
afford because nobody (to within experimental error) uses it. As soon as 
users demand more from news, or a commercial vendor offers extended 
features (EEE-style), it will suffer from the same problems the web and 
email did. I'm not sure if binary news already suffers the problem; I 
don't use it.

> 
>> That's the part that needs a massive revolt and there neither gopher
>> nor gemini will be the solution.
> 
> The solution is a web that's simple.  The protocol seems to be doing
> well enough, but the browser is a total disaster.  If only a handful of
> people can build it, it's a total disaster.  Without diversity, there's
> no resilience.
 >

Agreed, but you can't get from here to there because of game theory - a 
force as fundamental as entropy.

[toc] | [prev] | [next] | [standalone]

#23777

immibis <news@immibis.com> writes:

> On 12/31/23 04:37, Julieta Shem wrote:
>> I don't know, but it's what happens right now.  All browser vendors
>> are major players, unlike NNTP servers, which are so simple that a
>> single person can implement in a weekend, so you find lots of
>> alternatives.  Not so with browsers.

[...]

> News sidesteps the problem for now by only being plaintext, which it
> can afford because nobody (to within experimental error) uses it. As
> soon as users demand more from news, or a commercial vendor offers
> extended features (EEE-style), it will suffer from the same problems
> the web and email did. I'm not sure if binary news already suffers the
> problem; I don't use it.

Even being plain text, writing a client is much harder than writing the
NNTP server.  The web made it exceptionally hard to build the client.
There are various usable clients for NNTP, e-mail; not so with browsers.

You got a point.

Perhaps we need to decentralize applications.  Maybe Google can build
the best /window/ for a browser and someone else builds the /bookmark/
and someone builds the be HTTP client itself.  You see what am I saying?
A computer system is made of various parts.  When I'm using a program
such as Firefox, why can't I have some kind of GNU EMACS for me to type
the address in the address bar?  When I'm using Gmail, why must I be a
hostage of that text editor they provide me with?

I would think that the future is like that.  I have my text editor and
any application that asks me anything loads that text editor so I can
type something.  

For instance, learning is very expensive.  Each new program requires you
to even learn how to type.  If you give lay users the ability to find
their favorite editor wherever they go, they will begin to care about
that too --- not just programmers.

[toc] | [prev] | [next] | [standalone]

#23786

On 1/2/24 05:07, Julieta Shem wrote:
> Perhaps we need to decentralize applications.  Maybe Google can build
> the best /window/ for a browser and someone else builds the /bookmark/
> and someone builds the be HTTP client itself.  You see what am I saying?
> A computer system is made of various parts.  When I'm using a program
> such as Firefox, why can't I have some kind of GNU EMACS for me to type
> the address in the address bar?  When I'm using Gmail, why must I be a
> hostage of that text editor they provide me with?

We can go a step deeper. Why should HttpClientLibCorp get to send the 
whole HTTP request? Why don't we have one component send the status 
line, and another send the Accept header? We could even break up the 
status line component, so that one component sends the G, and another 
component sends the E, and another component sends the T.

> I would think that the future is like that.  I have my text editor and
> any application that asks me anything loads that text editor so I can
> type something.

I remember OLE too! And every web browser pane is Internet Explorer!

> For instance, learning is very expensive.  Each new program requires you
> to even learn how to type.  If you give lay users the ability to find
> their favorite editor wherever they go, they will begin to care about
> that too --- not just programmers.

facetious?

[toc] | [prev] | [next] | [standalone]

#23793

immibis <news@immibis.com> writes:

> On 1/2/24 05:07, Julieta Shem wrote:
>> Perhaps we need to decentralize applications.  Maybe Google can build
>> the best /window/ for a browser and someone else builds the /bookmark/
>> and someone builds the be HTTP client itself.  You see what am I saying?
>> A computer system is made of various parts.  When I'm using a program
>> such as Firefox, why can't I have some kind of GNU EMACS for me to type
>> the address in the address bar?  When I'm using Gmail, why must I be a
>> hostage of that text editor they provide me with?
>
> We can go a step deeper. Why should HttpClientLibCorp get to send the
> whole HTTP request? Why don't we have one component send the status 
> line, and another send the Accept header? We could even break up the
> status line component, so that one component sends the G, and another 
> component sends the E, and another component sends the T.

If it would be so desired.  Taking me as a particular example, all I
care about is the interface.  It seems it would be very useful if we
could reuse more interfaces.  I don't even care if my text editor is the
GNU EMACS or not, as long as it behaves just like it.  Why should I have
to type on a different software?  Text editor is text editor.  Why do we
need so many of them everywhere on the same computer system for the same
user?

>> I would think that the future is like that.  I have my text editor and
>> any application that asks me anything loads that text editor so I can
>> type something.
>
> I remember OLE too! And every web browser pane is Internet Explorer!
>
>> For instance, learning is very expensive.  Each new program requires you
>> to even learn how to type.  If you give lay users the ability to find
>> their favorite editor wherever they go, they will begin to care about
>> that too --- not just programmers.
>
> facetious?

I beg your pardon?

[toc] | [prev] | [next] | [standalone]

#23795

Julieta Shem <jshem@yaxenu.org> writes:

> I don't even care if my text editor is the GNU EMACS or not, as long
> as it behaves just like it.

Phase 1 - denial:

+ "There is no Emacs locked in syndrome!"

+ "I can use every editor as long as it behaves like Emacs."

+ ...


Welcome to the anonymous Emacsers!  Take a seat, grab a cookie...

-- 
I do not bite, I just want to play.

[toc] | [prev] | [next] | [standalone]

#23809

yeti <yeti@tilde.institute> writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> I don't even care if my text editor is the GNU EMACS or not, as long
>> as it behaves just like it.
>
> Phase 1 - denial:
>
> + "There is no Emacs locked in syndrome!"
>
> + "I can use every editor as long as it behaves like Emacs."
>
> + ...
>
>
> Welcome to the anonymous Emacsers!  Take a seat, grab a cookie...

:-) 

I like it because of the Lisp language.  The Lisp language seems to help
it to be what it is, self-documented et cetera.  It is important even
for the pleasure we derive from it while using it.  Technical people
seem to like software that gives them a sense of control, which requires
a precise understanding of the software.  So a self-documented
interactively-modify-it software helps us to understand precisely how it
works, which then turns into a enjoyable-to-use system.

  ``The details of the interaction matter, ease of use matters, but I
    want more than correct details, more than a system that is easy to
    learn or to use: I want a system that is enjoyable to use.  This is
    an important, dominating design philosophy, easier to say than to
    do.  It implies developing systems that provide a strong sense of
    understanding and control.  This means tools that reveal their
    underlying conceptual model and allow for interaction, tools that
    emphasize comfort, ease, and pleasure of use [...].  A major factor
    in this debate is the feeling of control that the user has over the
    operations that are being performed.  A `powerful,' `intelligent'
    system can lead to the well documented problems of `overautomation,'
    causing the user to be a passive observer of operations, no longer
    in control of either what operations take place, or of how they are
    done.  On the other hand, systems that are not sufficiently powerful
    or intelligent can leave too large a gap in the mappings from
    intention to action execution and from system state to psychological
    interpretation.  The result is that operation and interpretation are
    complex and difficult, and the user again feels out of control,
    distanced from the system.'' -- ``User Centered System Design'',
    capítulo 3, ``cognitive engineering'', ``on the quality of
    human-computer interaction'', pages 48--49, Donald A. Norman, CRC
    Press, 1986, ISBN 0-89859-872-9.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.misc

csiph-web