KDE HIG: What do you do?

Thomas Zander 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
> documentation.

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):
http://www.koffice.org/developer/apidocs/
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' 
in it.
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 ;)
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20061013/21a7ad91/attachment.sig>


More information about the kde-core-devel mailing list