[wiki] Textbook Terms and Terminology

Destry · 2009-01-08 21:42:36

Hi Saccade,

I like “content elements” as it makes it clear what kind of “elements”, specifically, as elements by itself could be vague to people if too far out of context.

P.S. I would just like to add that I think it is great you have taken active interest in the translation work and hold dialog on these things like you are doing. Truly great. I only wish more of the translation reps — or anybody — would do the same thing for other languages. It would be really interesting and positive in a number of ways. You should try and engage more German speakers in your efforts.

By the way, I got your email about the pages needing deleted. I’ve added you to the custom LangLeads user group (see Special:ListGroupRights, which is new group I created specifically for translation reps (that’s the new group now instead of making them wiki sysops) so you should be able to delete your own German pages now (you can delete any page, but it should just be those you are working on yourself, as necessary). Give it a try and let me know how it goes.

Last edited by Destry (2009-01-08 21:45:01)

saccade · 2009-01-08 21:53:48

Thank you!
It’s a great pleasure to contribute to textpattern and to its friendly community :-)

btw: I wish you all a happy new year!

I will try out the groupRights later this evening.

saccade · 2009-01-08 23:31:48

just to prove the concept: in Files I tried to follow the proposals.
Still think about “catalogue” instead of list.

And I add another proposal:
Sometimes the panel changes its view (but without an explicit message, what happened, see below) for presenting an edit dialogue, e.g. when editing the files properties or image properties or links properties.

Obviously there isn’t any noticeable indicator, where we are. The tab stays the same, there is no header, and only the title in the website’s header indicates something, but not too specific (and I personally don’t look there while working on a panel anyway):

active Panel	Title normal mode	Title edit mode
Images	Images	Edit image
Files	File	file
Links	Links	Links
Comments	Comments	edit comment

(Does this need some standardizing in the core?)

Edit (I forgot the proposal): In describing what happens I say “the panel view will switch to edit-properties-mode”. So I propose something like

“panel view”
“switch”
and “edit properties mode”

Last edited by saccade (2009-01-09 15:47:23)

saccade · 2009-01-09 08:18:24

@Destry: ListGroupRight work for me – and I hope not to make any mistakes :-)

Here the next proposal:

The “pieces of information” given to a content elemment (such as ‘description’ an assigned ‘category’ and like that) as far as I see are mentioned as “pieces of information” or “properties”.
In german that would make “Eigenschaften”.

What bothers me a little is, that this (“edit the properties of an image/file…”) easily could be mistaken as a files’ physical properties, e.g. ‘writable’ or in images the dimensions, color depth and like that. Or generally spoken: As to edit the content itself.
In german “Eigenschaften des Bildes bearbeiten” (edit the images’ properties) definitely will be understand as to modify the image itself and would lead to false expectations.

I looked for another term instead of properties=Eigenschaften but couldn’t find yet.
I think it has to be compounded in the following way (at least for the german side):

properties of the content element
(de) Eigenschaften des Inhaltselements

to make clear you can edit mostly the properties of the content entry.

Does this make sense? Is there a better solution?

Last edited by saccade (2009-01-09 08:19:19)

saccade · 2009-01-09 08:32:10

Next one:

pagination of lists of articles/images/files/links/comments if the list doesn’t fit on one page.
Is the term “pagination” common in english?
In German the correct one would be “Paginierung” but it is very uncommon, very technical language.

Also I think it would be fine to have a term for the pagination’s “pages’ navigation” with “previous/next”.
But “page navigation”/(de)“Seitennavigation” seems to general, because it could easily be mixed with the main navigation of panels.

Or simply summarize all under “pagination”/(de)“Paginierung” as a concept term and hope to coin/mint the term?

Destry · 2009-01-11 01:29:33

saccade wrote:

Is the term “pagination” common in english?

Pagination is a common enough word in English that when used, which is usually in context to technical topics, people know what it means. So, yes, it’s technical, but it’s an expected term in such cases and avoiding it is probably unwarranted. However, you could say “page navigation” or “previous/next navigation” and no meaning would be lost.

I’m sure you’ll come across many instances in all of this translation where you can’t make a direct match-up of the terms between two languages. That’s OK, you describe the concept being conveyed in the best terms for the language, and not get to hung up on the specific semantics. At least I find when translating French to English (the only way I can go, oddly enough), I can often not make direct translations of words and expressions. French is pretty wordy at times. :]

saccade · 2009-01-11 12:45:48

German also often is a lot more text to tell the same thing. I love my language, but I also like to express things as short and tight as possible – the only reason why I write lenghthy thoughts about the right terminology (sorry for that, but I can’t help). You have to work it out, then it will fit a broad range of tasks. But regarding briefness I’m sometimes a bit jealous at the english language. ;-)

On the other hand I have in mind that the TextBook articles should be helpful not only for developers of websites and designers, but also help people who are quite fresh in this area to understand the basic concepts (even if they only look for a how-to in a special case) – especially the content-pages should be helpful for mere author-users. For this reason I described some things more in depth on the pages I edited.
For someone who starts webdevelopment for the first time and begins textpattern there is a chance to lay solid foundations of webstandard-conform concept and logic (e.g. hardcode links or regard them as content elements).

As a student I worked as a proofreader for software manuals and tutorials (commercial books of a publishing house) and read hundreds of them. I often noticed where there is a point, where a user will loose the thread. (sometimes – very seldom – I even could improve something – but please don’t blame me for the other, I only had to proofread very fast, not to lectorate). So I developed high demands on manuals, which is why I like to help Textpattern get a very good one.

Direct match-ups of languages aren’t what I look for, but I like to have the very best word in a language for a worked through concept of explaining things. Sometimes it’s also a question of how to interpret or read a thing. If you have a reasonable, evident concept of how to explain it may be even not quite match the technical structure behind – but it will help people to do things they want to do.

For example take the “search function” in article lists (and other content elements). From a technical view it is a search function or a filter function, whatever term you like. From the view of users there are two things they want to do: Sometimes they want to search an article by its title or some kind of content. But often (when there are thousands of articles) they only want to see a subset, that is they want to filter the list for e.g. an author, to browse in that subset.
So I tried to get this “reading” of the function in its explanation. In consequence this will lead to the subtitle “Search and Filter” or like that.
If it’s only regarded as “Search function” some users will never discover that they can use the function to view a list of only their own articles.

And also I try to avoid “Äquivokationen” (missing the english term, should be ‘equivocations’, equal words meaning totally different things). They are numerous and a big problem for most users. Most of my time explaining software to people has to do with getting different things apart. So I look for ways to get terms different enough to be very clear from the beginning. Then of course there has to be a consistency in using them.
E.g. “page navigation” (in general ‘navigation of pages on the public-side’ – not necessarily between a numbered range of sub-pages – or ‘navigation between numbered sub-pages of an article list’ on the admin-side) and “link lists” (as a list of links on the public-side or the list of link-elements on the admin-side.)

You see, it’s a lot of things I try to do. I hope it will not annoy anyone.

Last edited by saccade (2009-01-11 13:13:38)

saccade · 2009-01-14 21:08:48

A new topic:
Reviewing “Write” again and again, I now want to make a proposal for naming the Write panel’s columns (only in TextBook for reference – not in Textpattern itself).

While I find the designation of its columns helpful and “stage” for itself nice, at the same time I think “utilities” “stage” and “settings” aren’t exactly matching and thus somewhat confusing. Also I have some difficulties to remember the triple and what is what.
E.g. “stage” for me is too obliged to presentation and motion software (Flash, Powerp.. and like that). A ‘stage’ for my imagination would require and lead to a lot of bells and whistles, but that may be only a personal approach.) Also it isn’t the whole “stage”. Something also happens in the left column, for example custom fields and image. Also if the powerful metaphor “stage” is used I think the whole thing/panel should stay within that picture/metaphor. Mixing pictures/metaphors is never intuitive. And here we have two metaphors at the same time: Theatre and Tool/Mechanism.
So I hope it is ok to look for another approach.

I tried to find out, which ideas (concepts, terms) most appropriate and intuitively reflect, what is actually offered in the columns.

Looking at the columns and what can be done there, we can say:

The mid-column is the main area, where article content will be edited. Main because it is not the only one (image and custom fields and keywords).

The left column offers additional options 1) how to edit (Textile), 2) what thing to edit (form and URL), and most important it offers additional content elements (image, custom fields, and keywords).
So I would sum up: It offers options for the editing of content.
Not least the column labels itself offer the term options.

In the right column we find things, that I think are best described as conditions of the content (an article) edited: It is “Live” or not, it belongs here or there, its comments are on or off and it has time conditions.

Main Edit Area sounds reasonable, explains itself and is comprehensible immediately.
“Options” and “Conditions” as terms in this couple I think play well together:
Options can be there or can be left out (like the things in the left column).
Conditions are always present/attached, it only depends on which conditions.

So I propose the following names for the three columns (written with Capitals to distinguish them from the normal use):

Options
Main Editing Area (or Main Edit Area?)
Conditions

Does that sound reasonable? Any comments?

Last edited by saccade (2009-01-14 21:15:21)

Destry · 2009-01-14 22:24:07

I agree it could be improved.

Options – OK, fits with the label that’s already there, but maybe not perfect. The right column has controls that provide options too (article state options, section and category options, date/time options…). Options might be too generic.

Main Editing Area – That’s better, but what about Article Editing Area, which specifically clarifies the nature of the editing area? (Or see below.)

Conditions – This one doesn’t click for me. It has connotations of ‘you can only do that if you do this.’ I actually think Settings is more logical here. When you have settings for something (article or anything else) you have a means for selecting a preferred set of values you want the thing to have, and which are often obligatory (even if just a default value). Further, it’s safe to say that everything in the left column are not settings at all, but “options.”

Another idea would be to not give the columns descriptive labels at all; instead, just call them columns by their location: Left Column, Middle Column, Right Column. (Ed. And apparently natural to do, as I just did it above without thinking about it.) :)

For example…

“In the left column of the Write panel you’ll find article markup options, form use options, custom fields (if desired), etc. The middle column is where you write and edit the primary pieces of the article (title, excerpt and body), and the right column provides you with the settings to publish your articles in relation to their topic context and your site’s architecture.”

I’m not suggesting to use that copy, but just showing that by referencing the column positions the descriptive copy is simple and perfectly clear.

The problem, however, is that Txp has labeled the left column as “Advanced Options” but not the others. I would say either that label should be removed, or the right column should be given a label too: Article Settings. The latter would be a positive usability change for that panel.

Last edited by Destry (2009-01-14 22:27:24)

saccade · 2009-01-15 13:43:43

OK, I see.
Article Editing Area doesn’t apply exactly for only the mid column, because at least you ‘edit’ as well in the left column. That’s the reason, why I thought of “Main” Editing Area, which will clearly indicate, that there are additional places to edit.
Condition I meant as “mode” (which already is in use for another thing). But you’re right, that it could be misunderstood as an “if”-clause.

And you’re right as well, given the highly improved interface of Textpattern 4.0.7 we don’t really need column names. (This was different before, when there weren’t the names and frames around e.g. “Sort and Display”-fields.)

So I’d decide to leave the names and only refer to the main editing area in the middle and “left” or “right” column. The images also will make it pretty clear.

I’ll revise that parts.

saccade · 2009-01-17 02:23:13

Now I have started revising the Write article. For the columns I’ll use simply middle/left/right, but give them description in the headers. I found this distinctions helpful:

Write Panel Middle Column – Main Editing Area
Write Panel Left Column – Options
Write Panel Right Column – Publishing Controls

Publishing Controls is exactly what the right column provides: Every aspect of publishing (or unpublishing) an article. This is more specific than the (in my view) too vague “settings” which I prefer to keep related to “preferences”.

Destry · 2009-01-17 20:36:29

Looks good. I hope it has boiled down to something that translates well to all languages.

saccade · 2009-01-17 20:54:11

Another question regarding headings:

There are two things I’d like to combine in a rather separated way:

Plain headings where panel modules (“Status”, “Expired”) are regarded,
and though some form of heading which will bring its use (or workflow or anything like that) to mind.

For example: “Timestamp – Time Management”
As they are now in Write I’m not quite satisfied – because one portion of (module) headings is really plain (and I think helpful), the other is different because of its additions, which on the other hand I don’t like to delete.

My idea: Is it possible to have a plain heading – and starting the paragraph below with a running in heading in bold? Like this:

Timestamp

Time Management. See (9). This setting might be considered two different settings because you use either one or the other, but since they both deal with the date and time that you associate with your new article, they are both discussed here.

Of course then is the question: Make the running in header any h4 h5 or simply bold text?

For “See (9)” I’ll post another proposal later.

Last edited by saccade (2009-01-17 20:56:04)

Destry · 2009-01-17 21:49:58

This is a good point. I vaguely remember having trouble with how to go about headings in some of the pages before too because of all the numbered topics (against the images). I would say your thinking is good and just go for it. If we need to adjust later no big deal.

I think it plays into the content too. From the cursory glances I’ve been able to give the admin-side panel pages, it looks like some need a word cleaver taken to them. A few of those pages need serious editing. There’s a lot of crap that could be dropped and facts that could be said more simply. Maybe after solid editing gets done, it will be easier to see how headings should used.

By the way, I’m not a big fan anymore of the big images with numbered/lettered items in them and trying to match the text copy against it. It’s asking for trouble, as it has already proven. If the admin side changes, the images are invalid and then both images and text need changed. I think a better approach from this moment on would be to simply refer to panel items/features in context by name/label or whatever and not by some forced numbering/lettering scheme in the images. Make sense? I’m not saying do all this yourself right now, but just that this is how it should be done going into the future and when people have time to give to it.

Which brings me to my last thought. I don’t have any time to edit pages right now, but if you do then I can only say have at it. Just do it and if they need changed later for whatever reason then so be it. It’s a wiki, so we can’t expect to be perfect the first time around. It’s often hard for new wiki writers (not suggesting you) to get overly attached with their contributions and/or treat the effort like someone would a reviewed article before publishing. But the truth is there’s not enough helpers, or time for the helpers we do have (me included) to analyze it too deeply too often. I wish the wasn’t the case, but it is, as history has shown.

Keep up the great work. You’re a star!

saccade · 2009-01-17 22:05:37

Thanks!, I’ll keep up editing.

Here my plans so far:
Finish “Write” (and possibly adjust geman translation).
Adjust images and propose how to handle references in a better way.
Then review “Article” and get some good patterns for the other content panels (where things are quite similar).

Then … enough work to come and a huge load of ideas emerging in my brain – let’s see what lasts.

One thing I’d like to introduce or at least think about:

Shouldn’t we make a simple “user” version of all content panels, with all admin/presentation/tag-things stripped and concentrated on the needs of editors and staff writers which will find a neatly paged/formed/styled site and only have to supply the content?
This at least is, what I seek for my clients.

Textpattern CMS

Textpattern CMS support forum

#16 2009-01-08 21:42:36

Re: [wiki] Textbook Terms and Terminology

#17 2009-01-08 21:53:48

Re: [wiki] Textbook Terms and Terminology

#18 2009-01-08 23:31:48

Re: [wiki] Textbook Terms and Terminology

#19 2009-01-09 08:18:24

Re: [wiki] Textbook Terms and Terminology

#20 2009-01-09 08:32:10

Re: [wiki] Textbook Terms and Terminology

#21 2009-01-11 01:29:33

Re: [wiki] Textbook Terms and Terminology

#22 2009-01-11 12:45:48

Re: [wiki] Textbook Terms and Terminology

#23 2009-01-14 21:08:48

Re: [wiki] Textbook Terms and Terminology

#24 2009-01-14 22:24:07

Re: [wiki] Textbook Terms and Terminology

#25 2009-01-15 13:43:43

Re: [wiki] Textbook Terms and Terminology

#26 2009-01-17 02:23:13

Re: [wiki] Textbook Terms and Terminology

#27 2009-01-17 20:36:29

Re: [wiki] Textbook Terms and Terminology

#28 2009-01-17 20:54:11

Re: [wiki] Textbook Terms and Terminology

Timestamp

#29 2009-01-17 21:49:58

Re: [wiki] Textbook Terms and Terminology

#30 2009-01-17 22:05:37

Re: [wiki] Textbook Terms and Terminology

Board footer