KDE HIG: What do you do?
zander at kde.org
Fri Oct 13 13:08:36 BST 2006
On Monday 09 October 2006 14:01, Celeste Lyn Paul wrote:
> For example, these are some simple task scenarios:
> So.. (in not so many words..) what do _you_ do? What are a sample of tasks
> or activities you perform (or plan to) when referencing interface
Some of this is already present on the developer.kde.org. The problems we
found to have there (over the years) is that different people have different
strategies to reach a piece of info. Often not finding it if the place in the
hierarchy is not as expected.
What I concluded from that is that we need heavy linking between all the
content we have.
As an example; when I was working on KParts and services I got a reference
from David to the howto on developer.k.o. Afterwards we added links from half
a dozen classes (api docs) to that howto which makes it easier to find even
if you don't start at the same class.
I imagine a similar approach for the hig would work;
> * Look up guidelines for all widgets where you have to pay attention to
> text formatting
Go to the widget in the API docs and click on the HIG link.
In the HIG chapter for that widget I expect a "This widget uses Camel Case
text formatting" with a reference link that explains everything in depth
(link is to a different chapter).
> * Learn more about dialog design and layout before working on a new wizard
Like here (in the bottom left frame):
I'd start at an overview of all items and expect one page with all the
relevant things about this kind of UI element (class).
I'd end up on the wizard page (or assistant as some want to call it) and see
its a dialog type (or at least, that's its main use). Which would contain a
link to all dialog types and layout rules for dialogs.
> * Find out if there is a standard design or implementation for search boxes
I'd be hard pressed to start from the HIG with this one. I'd start with the
same list of all classes and see if there is a class with the word 'search'
Maybe an extra feature that can be added to the online api docs (ade, you
listening?) where there is a search page and the results page would show an
image that is datamined from the apidox page showing what the class would
visually look like.
So, I'd go to docs.kde.org/api and search for "search". Check the checkbox for
"visual class", make sure the "data class" is unchecked and I'd see a page
with all classes and a screenshot next to them. I can select the class I want
really fast like that
If others here think they find my way of working pretty odd, please reply tell
Celeste what you would do instead ;)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the kde-core-devel