Bug 3161 - Bugzilla component for the "UI spec"
: Bugzilla component for the "UI spec"
Status: RESOLVED FIXED
Product: maemo.org Website
Bugzilla
: unspecified
: All All
: Low enhancement with 4 votes (vote)
: 4.1.1
Assigned To: Andre Klapper
: Ferenc Szekely
:
:
:
: int-62935 3116
  Show dependency tree
 
Reported: 2008-05-14 02:54 UTC by Ryan Abel
Modified: 2008-10-07 16:43 UTC (History)
4 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Ryan Abel (reporter) maemo.org 2008-05-14 02:54:00 UTC
One of the big blockers we, as community members, frequently run into when
reporting bugs and requesting enhancements is the mythical, impregnable,
mysterious "UI specification". We have practically no knowledge of what this
specification entails and, particularly frustrating here, is that non-Nokians
(seemingly) have no way of influencing or amending it. This situation is even
worse when you consider how much of an impact it has on the platform.

As such, I'd like to request two specific things and address one larger change.
First, that a bugzilla component for the UI specification be added (and have an
internal amendment process attached to this, of course) so community members
have some recourse to turn to when their bugs are shut down due to "UI spec"
issues, and, second, that (at least the important, general parts) of the UI
specification be documented and opened up on maemo.org (actually, this may
already partially be true and I've just not been able to bring pull up the
documentation with my searches).

More generally, I'd like to see the process behind the creation and amendment
of UI specification become more open to community involvement. It's an
incredibly frustrating issue for a lot of community members, as there's a
feeling of complete impotence with regards to the "UI spec", and giving us at
least a small voice in its direction and formation would help alleviate a lot
of the frustration and could very well bring about some good changes for
everybody.
Comment 1 krisse 2008-05-15 01:32:15 UTC
Definitely agree with this one. There are some bad bugs made worse by the UI
spec, and it seems unlikely that the writers of the UI spec anticipated these
situations. If that's the case then there should be some way for us to ask for
specific amendments to the specification, backed up by examples of how the spec
is preventing the resolution of other bugs.
Comment 2 Andre Klapper maemo.org 2008-05-26 13:10:47 UTC
creating a "UI Specification" product makes sense to me instead of just closing
bugs as invalid, so i went ahead and added it:
https://bugs.maemo.org/enter_bug.cgi?product=UI%20Specification

i haven't set proper default assignee contacts and qa contacts yet, this
workflow still has to be defined yet and is on my todo-list.
Comment 3 Quim Gil nokia 2008-05-28 08:15:16 UTC
Thanks Krisse, I just noticed this one. Your _Range Against the Machine_ is
understandable, however the way you have resolkved to approach it has room for
improvement.

- First of all the "UI Specification" is less of a product and more of an
element present in many products, like security or localization. A tag would be
probably more appropriate, and (I think) aligned with the internal error
management process. Then (I think) bugzilla offers tools to list and watch "UI
Spec" bugs only, giving at the end the same visibility and possibility to
follow.

- If you still want to go for the specific product path, then you might want to
consider renaming it to "User Interface", since the UI Specification is just an
artifact to define the way the UI works. But if you do this it will be even
more clear the potential confusion: "I have a potential bug in the UI of the
Clock, should I submit it to the UI product or the Clock product"?

imvho filing the bug in the Clock product and flag it with the UI tag would be
the right way.
Comment 4 Quim Gil nokia 2008-05-28 08:57:54 UTC
Oh, and by the way. Do not accept bugs or very sensible enhancement requests
closed or left out by an engineer because of "according to the UI specs", or
just any spec. All the software is subject to improvement and all the
requirements and specs defined in order to develop that software too. 

If there are good but perhaps not that evident reasons to do something in a
certain way, these reasons need to be provided and be convicing. Or at least
aimed to be sensible and convincing.
Comment 5 krisse 2008-05-28 10:50:10 UTC
Quim, I didn't propose this bug, it was the person who posted the first
message. I was just supporting the general idea of reporting problems with the
UI Spec.

I didn't choose this approach because I don't know anything about the
difference between a product and an element. I wouldn't have dared to start
something like this.


(In reply to comment #3)
> Thanks Krisse, I just noticed this one. Your _Range Against the Machine_ is
> understandable, however the way you have resolkved to approach it has room for
> improvement.
Comment 6 Andre Klapper maemo.org 2008-05-28 13:26:10 UTC
hi quim,

(In reply to comment #3)
> - First of all the "UI Specification" is less of a product and more of an
> element present in many products, like security or localization. 

hmm, we also have "Translations". :-) but of course you're right, yeah.

> A tag would be
> probably more appropriate, and (I think) aligned with the internal error
> management process. Then (I think) bugzilla offers tools to list and watch "UI
> Spec" bugs only, giving at the end the same visibility and possibility to
> follow.

no, you cannot watch bugs marked with a specific keyword. instead you can only
watch [virtual] users (like default assignees or default qa contacts) by adding
them to your watchlist. default assignees or default qa contacts depend on
products and components, so from a technical point of view creating a new
product is easier to handle.
other workarounds for the sake of completeness: subscribe to rss query results
or run periodic queries to email (so-called "whining").

> - If you still want to go for the specific product path, then you might want to
> consider renaming it to "User Interface", since the UI Specification is just an
> artifact to define the way the UI works. But if you do this it will be even
> more clear the potential confusion: "I have a potential bug in the UI of the
> Clock, should I submit it to the UI product or the Clock product"?

i am against using "User Interface" because i had very bad experiences in Gnome
Bugzilla. People will start filing everything under this product because "they
see their bug on the screen so it is part of UI". I'd like to keep calling this
"UI Specification" because to my impression there are enough people around that
already had some struggle here because this term was thrown at them in the
past. ;-)

> imvho filing the bug in the Clock product and flag it with the UI tag would be
> the right way.

it IS one possibility, but as explained you will not be able to watch/subscribe
to UI-specs bugs only.
Comment 7 Ryan Abel (reporter) maemo.org 2008-05-28 17:17:35 UTC
(In reply to comment #3)
> Thanks Krisse, I just noticed this one. Your _Range Against the Machine_ is
> understandable, however the way you have resolkved to approach it has room for
> improvement.
> 

Forgive me my frustration, but, well, as we've been in this ridiculous
situation for more than two years now, there wasn't a whole lot else _to_ be
done. Pretty much all complaints about it had gone unnoticed or ignored, so
_something_ had to happen to get the ball rolling. After you pound your head on
the wall with an issue like this for long enough, and lacking a better
direction . . . well, here we are.

> - First of all the "UI Specification" is less of a product and more of an
> element present in many products, like security or localization. A tag would be
> probably more appropriate, and (I think) aligned with the internal error
> management process. Then (I think) bugzilla offers tools to list and watch "UI
> Spec" bugs only, giving at the end the same visibility and possibility to
> follow.
> 

Quite honestly, I'm not particularly hooked on any one implementation. Really,
what I want is the ability to get in touch with _SOMEBODY_ when we hit the wall
with braindead UI stuff like bug #3116, or bug #2888, or bug #3152, or bug
#3151, or bug #971, bug #1811, or bug #230, or bug #303 etc, etc. As it stands,
the only people we really interact with here are people seemingly incapable of
making what (for all intents and purposes) should be simple fixes (i.e. the
engineers) due to this mythical "UI spec" that gets pulled out of the hat like
some horrible rabbit.

(In reply to comment #4)
> Oh, and by the way. Do not accept bugs or very sensible enhancement requests
> closed or left out by an engineer because of "according to the UI specs", or
> just any spec. All the software is subject to improvement and all the
> requirements and specs defined in order to develop that software too. 
> 

If only somebody had thought of that years ago. ;)

What else is there to do? As I said before, we only seem interact with the
engineers on these things, so "not accepting" their resolution mostly ends in
no-activity abandoned bugs or lots of unproductive, useless headbutting with
the engineers.

"Not accepting" would be fine if it ever seemed to get us anywhere, but it
doesn't, thus, the UI specification product, which might hopefully lead us into
communication with somebody who can actually do something other than pull out
that horrible "UI spec" rabbit.
Comment 8 Andre Klapper maemo.org 2008-10-07 16:43:13 UTC
(Removing deprecated "Future" Target Milestone.)