Re: Improving Quality



An end-user experience.

I am testing Fedora21. Between Fedora20 and Fedora21, at this point in time, execution efficiency for the interface lies with Fedora20.  Perhaps in the Fedora Alpha-rc1, there is much extra code for debugging and "assert macro" calls and this will disappear at time of  "Go Live". 

With testing, I found I could not load some existing (Web) Gnome Extensions. Is someone looking at these "Web" extensions, since Vanilla Gnome (Fedora21), is not enough useful to leave Fedora20 for version 21, given the tweaks that make Gnome more usable.


Off Topic.
With the ALL display, next to each glob (DOT), could Gnome include the  first character of the corresponding icon that would be displayed at location (1,1) on the screen.

Justification.  If I am searching for a program beginning with M, Within the All display, I can, with one click, arrive at the beginning of the M s.  
 
Regards

 Leslie
Mr. Leslie Satenstein
SENT FROM MY OPEN SOURCE LINUX SYSTEM.



From: Allan Day <allanpday gmail com>
To: Matthias Clasen <matthias clasen gmail com>
Cc: desktop-devel-list <desktop-devel-list gnome org>
Sent: Wednesday, September 24, 2014 5:45 AM
Subject: Re: Improving Quality

Matthias Clasen <matthias clasen gmail com> wrote:
...
> I think this is a great idea. When we discussed this at Guadec, I got
> the impression that we should use this to draw attention to
> longstanding UX annoyances, early enough in the cycle to address them.
> Here is a short list of (my personal) candidates for this category:
>
> 728496 evolution-data-server - Gnome shell keeps poping modal dialog
> for gmail password
> 710848 polari - private messages vs shell chat
> 705177 gnome-shell - Full-screen apps disappear on Alt+Tab

We'll need some guidelines for which bugs we include, and for what the
list should look like as a whole. My idea for this would be something
like:

* Bugs should affect user experience quality - commonly experienced
papercuts, lack of polish, or enhancements that would make a positive
difference.
* Only bugs from core applications and modules should be included.
Priority should be given to the most generally visible issues.
* Bugs shouldn't be allowed to linger on the list without an
identifiable solution.
* The vast majority of the bugs should be in a fixable state.
* At any one time, the list shouldn't be longer than 40 [?] issues.
* The list should contain a mix of issue types, ideally including a
combination of easy polish fixes and more difficult tasks.

There are possibilities to be systematic about which issues we
prioritise. I'd really like to have scheduled walkthroughs during the
development cycle, for example - and we could use those to populate
the list. Likewise, user testing results or results from QA testing
could be fed in. Of course, if we do that, the list could get quite
long - so that would require some thought.




Allan
_______________________________________________
desktop-devel-list mailing list
desktop-devel-list gnome org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]