Re: UMO Edit screenshot, take two

["Alexey Parshin" <alexeyp@gmail.com>]

2008/9/5 Anatoly Volynets <av@total-knowledge.com>

Some more. "Translate" button is above "Select a Language" drop-down.
They have to either trade places or even better be joint in "Translate
to:" drop-down, which would start translation as soon as language selected.

 

Translate button and combobox can be swapped - it isn't a big deal. I was just trying to make a sentence: [Translate to] [Language].
 

Generally, order of 4 controls "Publish", "Translate to:", "Save" and
"Delete" has to be well thought of. Probably "Delete this Object" button
has to be placed somewhere aside, say - in very top right corner. Also,
we had specified (I think) something like "Unpublish" (could be also
"Peer review", etc. options, so that "Publish" would either be an item
in a drop-down, or in option button).

It's the first time I hear about Unpublish. Before, it was always stated that Publish is final. Can you give me a link on description?

 

Two controls "Language(?)" and "View" can also be joint in drop-down
"View in:" which acts on selection.

The approach 'execute after selected in dropdown' isn't used for the following reasons:
1) I was limited not to use JS (please confirm)
2) It is good for View (because it doesn't modify anything)  but dangerous for Translate (one may just want to see the list of languages)

 

Anatoly Volynets wrote:
> Below is the same message as the previous one with few corrections.
>
> The UI presented looks like if we agreed that _any_ UMO can have as a
> child and be a child of _any_ UMO. For example a Problem can have a
> Course child. I conclude this because example presented contains DOT
> (Dialogue of Texts) as a child of Topic, while there initially were 3
> top level UMOs: Course, DOT and Through Problem. I don't actually mind,
> but am not sure that was meant to be so from technical point of view.

Not exactly. The screen shows Edit UMO, and presents all the children that exist for this UMO. The attaching UMO is a diffrent story and would depend on UMO type. It would be added on this screen on the next iteration, and would not allow to attach incorrect UMO types. And DOT is another story because they contain references not children :)
 

> I don't think a field title (Language, Description, Action) needs to be
> copied with every single UMO. Its content is intuitive, thus title can
> be either omitted or stated one or two times - at the top and bottom of
> the corresponding column. General names like "Explanation" need not to
> be there, because they are repeated in "Explanation 1" etc. names. If
> column titles used, it can be "Object Type" there.

The 'Explanation1' is just the test record. It has the word 'Explanation' in it just by a coincidence. It can be anything like 'Speaking of the bunnies'.
So, the idea of using general names here is to indicate the child UMO group, since the children UMOs are of the different types. The screen is also missing 'Attach' button in every group of the child UMOs.
 

>
> Functionally the page is fine. Graphic design bothers no one as of
> today... I think.
>
> Alexey Parshin wrote:
>> Now - with lemon juice! Oh, sorry - with request language support.
>>
>> Description:
>>
>> By default, UMO content and title are shown in user preferred language, or
>> in this UMO default language - whatever is available.
>> The new feature, request language, allows to select view language from
>> available (translated) languages in this UMO' content. Once selected, this
>> language is passed to any operations performed on this UMO from UMO Edit
>> page such as:
>>
>>    - Save
>>    - Edit child UMO
>>    - Publish
>>
>> Translate UMO operation also changes the request language to the language of
>> translation, so Translate operation shows UMO in the correct language.
>>
>> Since last time unrelated screen elements caused some confusion, I've cut
>> off everything but the work area.
>>
>

--
Anatoly Volynets, President
total-knowledge.com
culturedialogue.org

--
Alexey Parshin,
http://www.sptk.net