User: Password:
|
|
Subscribe / Log in / New account

The GNOME project at 15

The GNOME project at 15

Posted Aug 15, 2012 5:36 UTC (Wed) by aryonoco (guest, #55563)
In reply to: The GNOME project at 15 by hp
Parent article: The GNOME project at 15

Thank you, thank you thank you.

I especially liked the part about those who yell the loudest do not necessarily represent the majority.


(Log in to post comments)

The GNOME project at 15

Posted Aug 15, 2012 19:57 UTC (Wed) by codewiz (subscriber, #63050) [Link]

> I especially liked the part about those who yell the loudest do not necessarily represent the majority.

Finding what the majority of Linux users really wants would be an interesting exercise.

Several reviews and blogposts on GNOME3 have been very critical, but one could dismiss them as the personal opinion of haters. Phoronix ran a user survey on GNOME 3 with ~8000 respondents, but it was opt-in so the GNOME development community did not seem to take it very seriously.

I have a feeling that GNOME 3 is much more controversial than GNOME 2 ever was, but nobody knows whether it's a vocal minority or 70% of the userbase. The GNOME developers don't seem to have a process in place to collect user feedback and react upon it, which makes me wonder how they can tell what changes to the UX actually constitute an improvement.

The Gnome Foundation could spend some money to run a serious usability study on Gnome Shell, similar to the one that Sun did at the time of Gnome 1 which led to many of the UI changes we saw in 2.x.

The GNOME project at 15

Posted Aug 15, 2012 20:34 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Are you sure that the design changes between the 1.x to 2.x were "popular" with the 1.x userbase when they were originally introduced? I don't remember it that way. And the parent article here gives a little snarky head nod to the fact that we went through a lot of this emotion before in the 1.x to 2.x transition. It is really worth going back and taking a detailed look at the 1.x to 2.x transition...really look at the initial reaction to the changes being planned and implemented which fell out of the usability study you hold up as a good idea. I bet the reaction really was not all that great and not all that different to what we are seeing this time around.

Moreover, throwing money at the usability issue to purchase additional expert manpower will not solve the perception problem. Changes are disruptive...even changes that adhere to expert state-of-the-art usability design considerations. Because fundamentally the userbase really does not appreciate what is and is not good usability in the same way that those trained in the art and science of usability do.

Experts in usability think differently about usability than untrained users do. And its far from clear to me that we as a userbase appreciate or even understand the value of usability experts. As users, we like what we like, we use what is familiar, we are seldom prepared to stop and think through the issues of usability as a product design exercise to meet the needs of anyone other than ourselves.

There is absolutely no way that you could take my personal preferences, design a product based on them, and then get many other people to enjoy using that product. And here's the secret that nobody in the linux using community wants to admit to themselves publicly. I'm typical for a linux user in that regard. As a breed we are conformist in our non-conformity. We are stereotypically individualists to a fault. Catering to any one of us, means not catering to vast sea of other permutations of personal preferences.

And... unlike actual shipping retail product lines, where changes can be introduced at physical product boundaries and not as software upgrades to existing physical devices...we've chosen a model where software changes are more fluidly applied to existing computer devices. We've created an additional mental burden for ourselves by taking advantage of the ability to extend the useful life of any computing device by continually upgrading its functionality with new software. But the cost of that is disruption to workflows as new software development moves forward and new UI concepts are introduced. Introducing new UI at time of purchase of a new computing device is less of a burden on the user, because there is a honeymoon period with a new device where users are willing to work with new UI as part of getting familiar with the new hardware device itself.

The GNOME project at 15

Posted Aug 15, 2012 21:30 UTC (Wed) by rleigh (guest, #14622) [Link]

Regarding the 1.x to 2.x transition, there certainly was a fair amount of criticism at the removal of a some options and functionality. But I think it's also fair to say that it was also fairly eagerly anticipated. GNOME 1.x had its fair share of UI inconsistency, segfaulting buggy applications, and options craziness, so there was also something to be gained by the UI simplification and application reworking. There were also a number of key improvements in GTK+: font rendering with freetype/fontconfig/pango replacing XLFDs, MVC widgets like the GtkTreeView. In other words, there was a lot of important, visible, technical improvement which greatly benefited both the user and the developer, and which led to improvements in all GNOME applications. As a developer, I couldn't wait to start using GTK+2.0. And while the desktop was a bit blander, it was still mostly usable, and more importantly, stable.

GNOME3, for me, doesn't bring anything by the way of major technical improvement. The loss of features and gross UI changes are not compensated by any important technical gains which benefit me as a user or as a developer, unlike for GNOME2.

The main change that I can see is that from what I read of the GNOME developers blogs, mailings etc., is that the main designer and developer focus is on the superficial, the interface. The easy stuff. There's little or no major focus on the hard stuff. The core libraries, inter-process communication, application frameworks. Can I copy and paste and share complex data between different GNOME applications? i.e. more complex than mere plain text and pixmaps. Can the applications share components, embed and drive each other? Where are the DCOM/OLE/DDE equivalents for GNOME which it promised in the early days? Last I saw, this died when the last bits of CORBA were excised from Gnumeric (it provided and could embed CORBA objects, such as graphs, which could have been shared with other applications). Yet there's lots of exciting new technology out there like ZeroC ICE, which is a modern replacement for CORBA. Is GNOME even considering these problems, let alone working on them? Look at the stuff Apple is doing with technologies like Core Data; and in the UI like Core Animation. These are fairly fundamental useful technologies which all applications can make use of. Is GNOME developing anything like this? While GNOME applications share the UI toolkit, there's very little commonality under the hood--they are all essentially separate programs which can't intercommunicate, and don't share much in the way of common libraries. GNOME ceded its technical goals in favour of superficial appearance, which is very much to its long term detriment.

The GNOME project at 15

Posted Aug 15, 2012 21:40 UTC (Wed) by ovitters (subscriber, #27950) [Link]

GNOME 3.0 was initially about removing all the deprecated things and focusing on all the new technologies that were made and used to replace them.

That you didn't notice these things is actually quite a compliment!

The GNOME project at 15

Posted Aug 15, 2012 22:11 UTC (Wed) by raven667 (subscriber, #5198) [Link]

> Moreover, throwing money at the usability issue to purchase additional expert manpower will not solve the perception problem.

I'm not sure about that, if there were good clear data with blog posts discussing it, screenshots, etc. describing the changes and the testing that lead to the changes that would do very much to assuage concerns. There is a strong perception that the GNOME 3 design process is not being driven by science and I haven't seen any solid information to dispute that perception.

The GNOME project at 15

Posted Aug 15, 2012 22:54 UTC (Wed) by jspaleta (subscriber, #50639) [Link]

Fine be skeptical... im all for skeptical. And I'm all for published data , archived stakeholder discussion, and overall process transparency as can be achieved in any development process. I believe those things have value and help to build an informed citizenry not just in political governance but in all participatory communities. And there is always room for improvement in process transparency.

However, if we are going to hold up the previous Sun design study from 2001 during the GNOME 1.x era as a gold standard on how to do it well...let's be realistic about what the end result will be with regard to perception by going back and really looking at the reaction to the changes made as a result of that study. I don't remember it being a hugfest. In fact if you look really closely at the history, its the Sun study that really kicked off the move to minimalist design meme that GNOME tries to really adhere closely to over the long life of GNOME 2.x and into GNOME 3.x. People want to gripe a lot about the pruning of options out out dialogs and other interface components...it started with that design study.

And that Sun study consisted of "novice" GNOME users unfamiliar with linux and GNOME... not existing GNOME users.... not those of us here right now. And that is important to keep in mind. I do not believe that more novice user testing of this sort is going to appease any of the most vocal who are chafing at the changes. I do however believe that more novice user testing will result in better long term designs which are more iOS and Android like simply because thats now the what novice and casual computer users are most familiar with.I do not assume that designs focused on the novice will be optimal for me or for anyone else here. In fact I sort of expect the opposite. And I'm okay with that. I know I'm not a good target audience... what everyone else reading this needs to understand is.. they aren't a good target either.

The GNOME project at 15

Posted Aug 18, 2012 10:38 UTC (Sat) by Jandar (subscriber, #85683) [Link]

> I do not assume that designs focused on the novice will be optimal for me or for anyone else here. In fact I sort of expect the opposite. And I'm okay with that. I know I'm not a good target audience... what everyone else reading this needs to understand is.. they aren't a good target either.

The opposite of "optimal" is "worst". So you okay with GNOME alienating all lwn-readers in the most effective way?

The GNOME project at 15

Posted Aug 16, 2012 5:13 UTC (Thu) by codewiz (subscriber, #63050) [Link]

> Are you sure that the design changes between the 1.x to 2.x
> were "popular" with the 1.x userbase when they were originally
> introduced? I don't remember it that way.

I remember the criticism of GNOME 2.x focusing essentially on 3 major issues:

1) The "spatial" file manager, with no UI to change it;
2) The file dialog no longer allowed keyboard editing the path;
3) The printing dialog lost some advanced options (the "<a href="https://mail.gnome.org/archives/usability/2005-December/m...">interface nazis</a>" thread).

The complaints died off after GNOME was fixed to address users' requests: the "Open each folder in its own window" option reappeared and was made the default and the file dialog was enhanced so that the pathname edit box would appear as soon as you start typing, with full completion.

I'm not sure whether the printing dialog has ever been fixed, but perhaps there are just too few Linux users who are passionate about advanced printing options. Though I was surprised to see control panels to configure Wacom tablets and even color correction, stuff that few professionals need, when at the same time GNOME 3 has lost the ability to set something as basic as the font size. Makes me wonder how the GNOME design process works.

> I bet the reaction really was not all that great and not all
> that different to what we are seeing this time around.
> Moreover, throwing money at the usability issue to purchase additional
> expert manpower will not solve the perception problem. Changes are
> disruptive...even changes that adhere to expert state-of-the-art
> usability design considerations. Because fundamentally the userbase
> really does not appreciate what is and is not good usability in the
> same way that those trained in the art and science of usability do.

Are the developers convinced that history is repeating itself and all the users complaining are simply being irrational? This is a very risky assumption without solid data backing it.

It could be that Linux users are indeed very conservative and change averse, but one should also consider the possibility that Gnome Shell may be a good fit only for a subset of desktop users.

> Experts in usability think differently about usability than untrained
> users do. And its far from clear to me that we as a userbase appreciate
> or even understand the value of usability experts.

The problem with usability is that it's an inexact science and anyone could call themselves an expert in the field. Why can't I call myself an expert too? Do usability experts always agree when they make design decisions?

The only way to verify whether a UI change was really an improvement is testing it with real users and see what happens. In the case of Gnome Shell, there are some similarities with the GNOME 2 transition, but this time around some people seem to believe that all criticism is bogus and will stop by itself if they keep ignoring it.

Here's my prediction: all criticism *will* eventually die off... but just because all the discontent users will have moved on to some other desktop out of frustration. It could be a small loss or 80% of the current userbase. Hard to tell without any data.

The GNOME project at 15

Posted Aug 16, 2012 16:41 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

> Are the developers convinced that history is repeating itself and all the > users complaining are simply being irrational? This is a very risky > assumption without solid data backing it.

I'm a user. I'm not being irrational. Thus your thesis that all users are being irrational is debunked. Are some users being irrational? Yes. Do some users have legitimate concerns? must assuredly. There's no need to over generalize with the language.

And I've done nothing else in this thread but repeatedly ask that someone go back and examine the history specifically to provide data that is not based entirely on human recollection of events specifically because I have convinced myself history is repeating. I'm always open to solid data with documented methodology.

> It could be that Linux users are indeed very conservative and change
> averse, but one should also consider the possibility that Gnome Shell
> may be a good fit only for a subset of desktop users.

Oh I take that further. No single desktop environment is good fit for _all_ desktop users. How about that for a truism. For the same reason why we have different styles of chairs and desks, no single design aesthetic is going to be a good fit everyone. So it is with computer interface designs as well. So yeah shell is only going to be good for a subset. I really don't think anyone is arguing that its going to be the best fit for everyone so really its a bit of a rhetorical bait and switch. And I'm also telling you that those of us here are not the subset to shoot for. We are not the mainstream, our preferences will never be the mainstream, we are a very poor design target. Anyone who designs something to suit me, is designing for mass market failure. Anyone who is designing a desktop which appeals to the majority of the readership here is designing for mass adoption failure.

> The problem with usability is that it's an inexact science and anyone
> could call themselves an expert in the field. Why can't I call myself an > expert too? Do usability experts always agree when they make design
> decisions?

Yes indeed, this really hilights one of the points I made previously about the perception of usability design. As an audience I do no think we appreciate what trained designers actually bring to the table. You clearly do not. Anyone who stands up and basically says ah that stuff is easy, anyone can be an expert at that, clearly has no idea. I really feel for the people who have actually been trained in design in our community for that reason. Constantly having to fight with people with no training who think they can do it better. Demoralizing really.

And i'm not going to name names, but I believe certain high-profile individuals have perhaps spoken out of place, abused their soapbox a bit, and spoken on behalf his private design team far too often even though he himself is not a trained designer. We don't need their managers talking for the trained designers. No more of that.

We absolutely need more of the _trained_ designers to step up and explain some core concepts to us, so we, the larger participatory community, can better appreciate the effort being made (even if we still don't like the final outcome). We must gain confidence in the skillset and the training as a profession. But in order for this to happen we are going to have to make a safe space for these people to start communicating out in the open without having to deal with you and the rest of the "I'm not an expert but I can do better than that" crowd.

The GNOME project at 15

Posted Aug 16, 2012 17:57 UTC (Thu) by codewiz (subscriber, #63050) [Link]

> And I'm also telling you that those of us here are not the subset
> to shoot for. We are not the mainstream, our preferences will
> never be the mainstream, we are a very poor design target.

There are plenty of mainstream interfaces that I use daily with great satisfaction: Android, Chrome OS, Maemo...

Over the past year I even considered going back to Mac OS X out of frustration for the sorry state of the Linux desktop. But in the end I love free software and I'm going to stick with it a little longer in spite of the miserable user experience that I'm getting these days.

I think we should stop hiding behind the belief that Gnome Shell appeals to a wider audience than just geek. At least, not until we have data showing that the market share has been growing since GNOME 3.0.

> Yes indeed, this really hilights one of the points I made previously
> about the perception of usability design. As an audience I do no think
> we appreciate what trained designers actually bring to the table.
> You clearly do not. Anyone who stands up and basically says ah that
> stuff is easy, anyone can be an expert at that, clearly has no idea.
> I really feel for the people who have actually been trained in design
> in our community for that reason. Constantly having to fight with
> people with no training who think they can do it better.
> Demoralizing really.

I'm not saying that UI design is easy! On the contrary, I'm saying that being trained in UI design and usability doesn't make you a good UX engineer any more than studying CS automatically make a good software engineer.

The only way to verify whether a UI designer did a good job is asking users to vote with their feet. We don't have solid data, but by now there are a some hints that something might have gone wrong with Gnome Shell: lots of bad reviews, critical blogposts, forks, major distros switching to other desktops and, last but not least, lots of negative comments in user surveys.

> We absolutely need more of the _trained_ designers to step up and
> explain some core concepts to us, so we, the larger participatory
> community, can better appreciate the effort being made (even if we
> still don't like the final outcome).

Sure, I'd be eager to hear detailed explanations from the trained designers backing some of the decisions that seem arbitrary.

I understand that part of the design was meant to make our UI more suitable to tablets and smart phones. However, so far we've failed to steal any significant market share from iOS and Android, while at the same time we've lost the largest Linux distributions.

> We must gain confidence in the skillset and the training as a
> profession. But in order for this to happen we are going to have
> to make a safe space for these people to start communicating out
> in the open without having to deal with you and the rest of the
> "I'm not an expert but I can do better than that" crowd.

Sure, let's give them some time to try their ideas, but at what point do we verify the actual results and make a decision to change strategy?

We don't have the luxury of infinite time and resources. If you do believe in history repeating itself, take KDE 4's fall: the initial release was such a gigantic fiasco that large portions of the user base switched to Gnome 2. Afterwards, the KDE developers put an admirable effort at fixing the bugs and polishing the interface, but the project did never fully recover.

The GNOME project at 15

Posted Aug 18, 2012 10:52 UTC (Sat) by Jandar (subscriber, #85683) [Link]

> [...] take KDE 4's fall: the initial release was such a gigantic fiasco [...]

This was not KDEs but only the distributions fault. KDE had 4.0 clearly labeled as beta, experimental, not ready for production use and capable to shoot into the users feet. At that time it wasn't thinkable for me to install such a beta desktop so I was astonished to see it had found way into the major distributions.

Following conventions

Posted Aug 18, 2012 12:55 UTC (Sat) by man_ls (guest, #15091) [Link]

We have heard the argument that KDE 4.0 was not ready for production before; I remain unconvinced.

When releasing software it is important to follow a set of conventions to your target audience -- in this case Linux distributions. A "x beta", "x rc" or "(x-1).99" version number signals a release not ready for a broad audience; while "stable" or "x.0" marks software ready for distribution. In this case, KDE should have used a different version number than "4.0" if they did not want general distribution. It is not enough to say that the version is experimental somewhere.

Besides, the 4.0 release announcement contains nothing of the sort. It appears to be a bona fide major release intended for public consumption; and the KDE project seems happy that it will be included in major distributions such as Fedora or Debian lenny.

My last argument is that it is the project's responsibility to communicate to distributions. When one recipient misunderstands the message but others get it right it may be the recipient's problem; when most recipients get it wrong then it is clearly the fault of the sender. At least if the sender cares about reaching message recipients.

So please, enough with blaming distributions. A gigantic fiasco it was; so let us accept it and learn from it.

Following conventions

Posted Aug 18, 2012 13:59 UTC (Sat) by Jandar (subscriber, #85683) [Link]

That KDE 4.0 wasn't considered production ready was communicated widely at that time.

Here one part of http://www.commit-digest.org/issues/2007-12-30/

Stephan Binner writes a reminder note about the upcoming KDE 4.0 release (in an attempt to reign in wildly over-optimistic expectations by some users):

Before everyone starts to spread their opinion about KDE 4.0, let me spread some reminders:
KDE 4.0 is not KDE4 but only the first (4.0.0 even non-bugfix) release in a years-long KDE 4 series to come.
KDE 4.0 is known to have missing parts or temporary implementations (eg. printing, PIM, Plasma).
Most changes happened under the surface and cannot be discovered in a "30 minutes usage" review anyway.
User interfaces being unchanged in 4.0 compared to 3.5 may be still > changed/improved during KDE 4 life time.
KDE 4.0 will not be the fastest KDE 4 release - like for KDE 2 most speed optimizations will happen later during KDE 4.
Most applications (many are not even fully ported yet) will take only advantage of new features which the new Qt/KDE libraries offer later.
Don't measure portability success (eg. MS Windows) by current availability of application releases, they will come.
KDE 4.0 is only expected to be used by early adopters, not every KDE 3.5 user (and IMHO KDE 4.0 shouldn't be pushed onto other user types like planned for Kubuntu ShipIt (which by the way is said to have only 6 months support for its packages)).
KDE 4.1 development will not require the same amount of time as the big technology jump of KDE 4.0: expect KDE 4.1 later this year.
Last, again: KDE 4.0 is not KDE 4.

Following conventions

Posted Aug 18, 2012 16:50 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

Widely communicated but not mentioned in the 4.0 announcement? Not even distribution maintainers got the message clearly. KDE people admitted their mistake and corrected the 4.1 announcement but it was a bit too late. That's alright though. We all make mistakes. Let's not go around engaging in revisionist history. That's just silly.

Following conventions

Posted Aug 19, 2012 11:59 UTC (Sun) by Jandar (subscriber, #85683) [Link]

I expect a Distribution maintainer to not only read one announcement. If the beta status was to a mere user like me totally clear, it is implausible a maintainer hadn't heard about it. This has nothing to do with revision of history but with minimal awareness about KDE at the end of 2007.

Following conventions

Posted Aug 19, 2012 16:00 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

KDE 4.0 announcement wasn't just for distribution maintainers but also for users so that excuse is weak especially consider 4.1 announcement did include such a note. You can either claim that distribution maintainers who KDE itself advertised as including 4.0 were incompetent or admit there were mistakes from the project.

Following conventions

Posted Aug 19, 2012 21:50 UTC (Sun) by nix (subscriber, #2304) [Link]

Uh, the 4.1 announcement included such a note *because* of the flap over the 4.0 announcement not including one. (I would have hoped that it was bleeding obvious that 4.1 was released after the reaction to 4.0 had been observed, but apparently not...)

Following conventions

Posted Aug 20, 2012 6:21 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

It is obvious but you miss my point. 4.1 did include such a note because KDE project realized that not making it obvious in 4.0 was a mistake from the strong reaction to it. Now nobody should be trying to blame it all on distributions.

Following conventions

Posted Aug 20, 2012 22:47 UTC (Mon) by nix (subscriber, #2304) [Link]

Any distro that thought 4.0 was stable and included it as such was a distro that had not been paying any attention to the prereleases (with subtle hints such as the codename 'Krash') nor even tried to run the thing for a while and seen just how far from perfect it was -- nor even hung out on the kde development lists and observed the same.

Following conventions

Posted Aug 20, 2012 22:56 UTC (Mon) by man_ls (guest, #15091) [Link]

That was about all distros, since all of them included KDE 4.0 as stable. So distros did not pay enough attention, just saw the release, took the thing and packaged it. As is their job.

Conclusions: do not rely on distros following development of your package; explain everything in detail in the release announcement. Do not use subtle cues; use standard version numbers where "4.0" means "stable version". Do not count on distro maintainers knowing your software intimately; go after them and explain any anomalies. They are providing your users a service packaging your software; do not expect them to also do your job for you, and above all: do not blame them for your failures to communicate.

As an upstream developer I see these things clearly, but perhaps big packages are different.

Following conventions

Posted Aug 20, 2012 23:22 UTC (Mon) by sfeam (subscriber, #2841) [Link]

That was about all distros, since all of them included KDE 4.0 as stable
This is a bit exaggerated. For instance Mandriva, which is/was primarily a KDE-based distro, carried KDE3 as the default configuration and offered KDE 4.0 only as an experimental option with suitable warnings in the 2008.1 installation instructions. They didn't switch to KDE4 as a default until the 2009.0 release containing KDE 4.1.1. Even then it came with warnings and an installation option to stick with KDE3 instead.

Following conventions

Posted Aug 20, 2012 23:26 UTC (Mon) by man_ls (guest, #15091) [Link]

So not everyone, thanks. Just curious, what did OpenSuse do? They are the flagship KDE distro and sponsor KDE development. Did they ship 4.0 as stable, or did they wait until 4.1?

Following conventions

Posted Aug 20, 2012 23:47 UTC (Mon) by sfeam (subscriber, #2841) [Link]

I'm not a OpenSUSE user, but Wikipedia states that 11.0 and 11.1 shipped both KDE3 and KDE4. OpenSUSE 11.2 (late 2009) was the first to offer KDE4 only, and by that point it was KDE 4.2.something.

Following conventions

Posted Aug 21, 2012 7:14 UTC (Tue) by boudewijn (subscriber, #14185) [Link]

Yeah... And that's also why KDE released two more 3.5 versions after 4.0 was released. Maybe it should have been more, and if distributions had asked for another 3.5 release, I'm fairly sure one more would have been released, since for some time bug fixes were going in.

Following conventions

Posted Sep 1, 2012 15:09 UTC (Sat) by rich0 (guest, #55509) [Link]

Not only that, but was 3.5 still maintained?

Distros generally ship the version of upstream that is maintained - that is the one that when you report a bug against it the bug is very likely to get fixed and posted in a new release.

Once 3.5 was abandoned, distros basically had little choice but more to 4. So then to say that it was only a beta/etc is a bit disingenuous.

Following conventions

Posted Sep 1, 2012 15:31 UTC (Sat) by hummassa (subscriber, #307) [Link]

KDE 3.5 was never abandoned. But it's true that most app devs got lured into the upgrade lure. 3.5.10 was relased in august 2008, when 4.1 was already out, and 3.5.13 was release as Trinity last year.

The GNOME project at 15

Posted Aug 18, 2012 23:58 UTC (Sat) by sramkrishna (guest, #72628) [Link]

Me too. It clearly said beta. Unfortunately, people say "4.0" and said "oh, stable". So I think the lesson there was to say "beta" and call it 3.99.9 or something like that.

The GNOME project at 15

Posted Sep 1, 2012 15:13 UTC (Sat) by rich0 (guest, #55509) [Link]

That, and keep releasing new versions that are lower-numbered.

You can't abandon KDE 3.5 and then say that people shouldn't have migrated to 4. The current version is whatever keeps getting bugfixes.

Most serious software packages don't just do all bugfixing at the bleeding edge. Heck, the kernel still has full support for v3.0 and v3.4, with later versions not having longer-term promises (they're the equivalent of KDE 4 or 3.99.9 or whatever).

The GNOME project at 15

Posted Aug 15, 2012 21:38 UTC (Wed) by ovitters (subscriber, #27950) [Link]

The Gnome Foundation could spend some money to run a serious usability study on Gnome Shell, similar to the one that Sun did at the time of Gnome 1 which led to many of the UI changes we saw in 2.x.

I have noticed (only lately) bugs that were filed as a result of usability testing. I asked for details and didn't get any response.. so I can only make assumptions. I'm guessing that a) only limited usability testing have been performed up to now b) it will likely increase as 3.x matures c) there are various things that designers/developers aren't happy with at the moment, so likely the lack of a big test is because things are still not considered to be good enough. There are still various changes being made to existing 3.x functionality; some are hard to notice unless you really follow all the NEWS files, bugs, etc.. or have really great attention to detail).

Some (don't mean Nautilus:P) of the issues people are complaining about are being changed in each newer version of 3.x. However, that is on a 6 month cycle and it sometimes takes multiple cycles to get things right. It seems some people expect changes within days.

On gnome-os-list there is a list of things they want to work really well. I personally would like another big usability study after that. That Sun one was awesome.

Note that various companies used to do usability testing. It was often talked about during conferences (how to setup your own small usability test).

The GNOME project at 15

Posted Aug 15, 2012 22:23 UTC (Wed) by hp (subscriber, #5220) [Link]

I think developers and designers often take flames and polls and the like as a data point saying "there is a pain here" -- but not as a prescription for how to solve it.

Most of the time flames boil down to the following:

  • I am a busy person with stuff to do.
  • I've learned a lot of half-unconscious habits that I use often to do my stuff.
  • I upgraded and some of my habits don't work anymore.
  • This is super annoying and I don't have time for it.
  • Who are these jerks hosing me? Just change it back.

This is completely understandable and I have the same emotion pretty often. I frequently avoid upgrading software especially to the ".0" release.

Sometimes, software should not have been changed. It's not better enough.

If there was some reason to change, the developer is in a tricky spot. They have to figure out how to satisfy both the reason for the change, and patch up the pain of the change. This is often genuinely hard.

Often when people are frustrated by a change they aren't willing to rationally discuss any option other than "just change it back" and that's what most of the flames end up being about. Developers may feel it's best overall (for users in general) to find a solution other than "just change it back" but if you're in the midst of being aggravated and unproductive you don't have the patience for trying to find the best answer. Having the development process out in the open just pisses people off in this situation, sadly, because they aren't looking to participate. They are just frustrated and trying to get stuff done.

It devolves into all kinds of tangents and speculations we're all familiar with (about people's motivations and what's wrong with the software industry and somehow everyone's complaints are what "the community" wants and my identity is at stake and I'm switching to XYZ and I should have been consulted and so on). Lots of drama.

Eventually somebody just has to buckle down and say "here are all the known issues and some possible solutions and pros and cons and let's figure it out," make another change that might improve matters, get feedback on that one, iterate again...

It's tempting to believe that software design can be a matter of taking a poll or doing some usability tests or some other mechanical system, but unfortunately that doesn't work. It would be nice if it did.

The GNOME project at 15

Posted Aug 16, 2012 1:24 UTC (Thu) by bojan (subscriber, #14302) [Link]

> Sometimes, software should not have been changed. It's not better enough.

> If there was some reason to change, the developer is in a tricky spot. They have to figure out how to satisfy both the reason for the change, and patch up the pain of the change. This is often genuinely hard.

Example: using 3D rendering. Hardware is already there, which can do a better job of it, relieve the CPU, lower the power consumption etc. So, changing the system to be able to take advantage of it is a good thing (while not breaking the system for setups that don't have 3D rendering). Full marks.

Example: overview. Gnome is primarily a desktop system, not a smartphone or a tablet system. Inventing philosophical reasons along the lines of "minimising distraction" (as if panel autohide didn't already exist and as if notifications could not be turned off) is an example of a change just for the sake of it. Because it was fashionable to do it. In the process, the visibility of the whole desktop was completely lost, GUI/mouse actions became more complicated, windows could not be properly minimised and users are now constantly exposed to completely unnecessary animations. It was not hard to figure out at all that there was zero need for this change on the desktop. Thumbs down.

Example: overview v. fallback mode. Depending on your hardware, Gnome 3 acts in surprisingly and almost entirely different ways. There is no functional reason for this (the main reason is overuse of animation). Both 3D and 2D versions could have been made to look more alike. Thumbs down.

Example: Nautilus type-ahead removal. A great example of a change without justification. Users tell developers that they use and like type-ahead, which is substantially different from search. Developers reply with: "it's gone anyway", because search is better (but it's actually quite something else). Thumbs down.

And so on and so forth.

If developers cannot come up with a genuine functional improvement as a result of a change, they should not be engaging in it.

The GNOME project at 15

Posted Aug 16, 2012 2:12 UTC (Thu) by hp (subscriber, #5220) [Link]

> If developers cannot come up with a genuine functional improvement as a
> result of a change, they should not be engaging in it.

Nobody changes things just for kicks. Truly.

There isn't some moment where people say "OK, I can't come up with any reason this is an improvement, but I'll do it anyway."

The GNOME project at 15

Posted Aug 16, 2012 2:16 UTC (Thu) by hp (subscriber, #5220) [Link]

Maybe it was my fault for saying "Sometimes, software should not have been changed. It's not better enough."

What I mean is with 20/20 hindsight, in retrospect sometimes it should not have been changed. i.e. people make mistakes.

The GNOME project at 15

Posted Aug 16, 2012 23:47 UTC (Thu) by bojan (subscriber, #14302) [Link]

As I said in some other posts, I think Gnome 3 can actually be fixed rather easily. The Cinnamon effort proves this quite neatly (unfortunately, it also creates even more desktop fragmentation).

The GNOME project at 15

Posted Aug 17, 2012 12:40 UTC (Fri) by codewiz (subscriber, #63050) [Link]

> As I said in some other posts, I think Gnome 3 can actually be fixed
> rather easily. The Cinnamon effort proves this quite neatly
> (unfortunately, it also creates even more desktop fragmentation).

I agree. I tried Cinnamon a while ago and I liked the concept, but I found it still a little rough.

Like Unity, Cinnamon probably had to patch the GNOME libraries or live with APIs designed exclusively for Gnome Shell. In recent times, multiple GNOME developers have advocated for tighter end-to-end integration across the software stack, which sounds like a polite way to say that they won't take patches from other GNOME-based desktops unless they benefit Gnome Shell directly.

The situation for distributors is less than ideal: they're being forced to either carry forked versions of upstream libraries, or ship Gnome Shell only.

(disclaimer: the above is based on what packagers are saying in multiple forums, I haven't looked at the patches in question).


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds