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 <[email protected]>
>To: Matthias Clasen <[email protected]>
>Cc: desktop-devel-list <[email protected]>
>Sent: Wednesday, September 24, 2014 5:45 AM
>Subject: Re: Improving Quality
>
>
>Matthias Clasen <[email protected]> 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
>[email protected]
>https://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
_______________________________________________
desktop-devel-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
