TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
I suggest, like it or not, stick to the same terminology that Eclipse uses. Your company based your product's interface on the Eclipse interface to make it quicker and easier for Interface users to learn your software. Because your stuff looks like Eclipse, they will have the expectation that your software will also be similar in how it is described. If you shift wording on them it will present them a bit of a stumbling block, which is exactly what user level documents are *not* supposed to do. That may be a minor stumbling block, but there is no really good reason for it to be there at all.
Of course, that approach may present a copyright problem. It would be a good idea to run the idea past your comnpany's chief counsel.
> From: MDoyle TStorer <storerdoyle -at- gmail -dot- com>
> Subject: Eclipse interface terminology
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Date: Friday, November 14, 2008, 11:48 AM
> The company where I work as an editor is producing an
> application developed
> using the Eclipse development environment. The interface
> real estate of the
> application largely mimics that of the Eclipse workbench.
> The writers (and
> I) are wondering how to refer to the interface elements.
> I've been looking
> at the Eclipse User Interface Guidelines available at:
>http://wiki.eclipse.org/User_Interface_Guidelines,
> but these are mainly for the Eclipse workbench itself. I
> would be interested
> to hear how other technical writers are approaching
> Eclipse-designed
> applications.
>
> The application window contains perspectives. "A
> perspective is a visual
> container for a set of views and content editors,"
> says the guideline, and
> "A perspective is like a page within a book. It exists
> within a window along
> with any number of other perspectives and, like a page
> within a book, only
> one perspective is visible at any time." Individual
> views can have tabs and
> tabs can have subtabs. Perspectives and views do not always
> have titles. To
> be honest, I'm not entirely sure when I'm looking
> at a view and when I'm
> looking at a perspective, and whether or not multiple tabs
> in a view mean
> the view is really a perspective (where each tab is a
> view).
>
> To me, the perspective/view terminology is not intuitive
> and would need to
> be defined, but in an online help system users are not
> always going to look
> for the topic that defines interface terminology. Windows,
> panes, areas,
> sections, zones, perspectives, views, tabs... the number of
> possible words
> to describe a user interface seems to be endless. Making it
> trickier to
> document is the fact that you can often pull the pieces
> around the screen
> and position them where you will; you can open and close
> them one by one;
> even when they're open, you can hide content by pushing
> it either up and
> down or to either side, with the space then being filled by
> adjacent
> content. This can easily lead to situations where users
> customize the
> display without realizing quite what they're doing, and
> are then confused
> about what they're looking at and how to return to the
> default display.
> Consistent, clear ways to talk about interface components
> is therefore all
> the more necessary in the online help.
>
> If anyone has any bright ideas or useful links or books to
> point me to, I
> would be very grateful! Thanks in advance.
>
> - Tom Storer
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> ComponentOne Doc-To-Help 2009 is your all-in-one authoring
> and publishing
> solution. Author in Doc-To-Help's XML-based editor,
> Microsoft Word or
> HTML and publish to the Web, Help systems or printed
> manuals.
>http://www.doctohelp.com
>
> Help & Manual 5: The complete help authoring tool for
> individual
> authors and teams. Professional power, intuitive interface.
> Write
> once, publish to 8 formats. Multi-user authoring and
> version control! http://www.helpandmanual.com/
>
> ---
> You are currently subscribed to TECHWR-L as
> klhra -at- yahoo -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit
>http://lists.techwr-l.com/mailman/options/techwr-l/klhra%40yahoo.com
>
>
> To subscribe, send a blank email to
> techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwr-l.com/ for more resources and info.
>
> Please move off-topic discussions to the Chat list, at:
>http://lists.techwr-l.com/mailman/listinfo/techwr-l-chat
ComponentOne Doc-To-Help 2009 is your all-in-one authoring and publishing
solution. Author in Doc-To-Help's XML-based editor, Microsoft Word or
HTML and publish to the Web, Help systems or printed manuals. http://www.doctohelp.com
Help & Manual 5: The complete help authoring tool for individual
authors and teams. Professional power, intuitive interface. Write
once, publish to 8 formats. Multi-user authoring and version control! http://www.helpandmanual.com/
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-