Hi Waleed,
We could make this configurable - the usual compromise in this situation.
- yba
On Fri, 15 Oct 2004, Waleed Hosny wrote:
> Hi Jonathan,
>
> I slightly disagree, I do not see a benefit for traditional user to see
> a character/mark that he do not understand and non printable and I still
> can not find a case where a traditional user will need to remove the
> marker without removing the weak character???
>
> If we need to give this feature for power/techi users then it should be
> an option and the user have to select to display/hide Bidi Markers (this
> way we ensure that the user knows what he is looking for) but by default
> we should not display it.
>
> Regards,
> Waleed
>
> Jonathan Ben Avraham wrote:
>
> >Hi Ilya,
> >Please see inlines below...
> >
> >On Fri, 15 Oct 2004, Ilya Konstantinov wrote:
> >
> >
> >
> >>Jonathan Ben Avraham wrote:
> >>
> >>
> >>
> >>>Hi Waleed,
> >>>I think that the user needs to see the LRM in some way so that he can
> >>>delete it if he wants to (and put it back afterwards if need be). It's not
> >>>good to have something invisible that changes the display of the text so
> >>>radically. As to the actual design of how to do this - that's best left up
> >>>to professional interface desingers.
> >>>
> >>>
> >>>
> >>>
> >>Am I correct that in some unbelievable way, we came to the decission
> >>that the end-user should be familiar with the Unicode BiDi Alogrithm's
> >>(UBA) workings? This is unthinkable, and at the same time quite expected
> >>when the software is being designed by techies with no UI Design people
> >>to overlook their work.
> >>
> >>
> >
> >The user does not need to understand Unicode or the bidi algorithm. We
> >provide the LRM automatically. The usere sees it and can delete it if he
> >wants to. The effect on the text is immediately apparent visually. This is
> >a self-teaching feature - if you can see the character that is causing the
> >change in the behavior. There's no learning curve here.
> >
> > - yba
> >
> >
> >
> >
> >>1. We started from the Microsoft Office implementation of BiDi controls;
> >>an implementation which manages, at the same time, to give the users
> >>precise control over direction, and to completely shield them from the UBA.
> >>2. Then somehow we slided to a heuristic-based algorithm, which works
> >>most of the times, and at times when it doesn't work, the user is
> >>expected to insert "control characters". You'll have a hard time
> >>explaining control characters to a non-techie...
> >>3. Then, finally, we have to the conclusion that the user needs to see
> >>those control characters. So, even if the heuristics work as intended,
> >>our non-techie would still be bewildered as to whether that "silly
> >>character" will come out in print. Not to mention that you'll have to
> >>explain the non-techie what zero-width characters are, and how come
> >>pasting such a character somewhere affects the formatting of the text
> >>before it.
> >>
> >>Yes, the UBA makes a lot of sense to all of us, and if the non-techie
> >>will spend a few hours understanding it, it'll make sense to him as well.
> >>Thing is: With Microsoft, this learning curve isn't required! As much as
> >>it doesn't make sense to us "UBA-purists", the "Input language affects
> >>direction" metaphor is *very natural* to the casual user.
> >>
> >>Let's look back at what we've done and think: Are we following the
> >>principle of 'let the user's work flow and interrupt him for
> >>technicalities as little as possible' ?
> >>
> >>Guys, I hate to be the party-pooper, but that's what UI Design's job is
> >>all about :)
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
--
EE 77 7F 30 4A 64 2E C5 83 5F E7 49 A6 82 29 BA ~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- [EMAIL PROTECTED] - tel: +972.2.679.5364, http://www.tkos.co.il -
==============================================================
To unsubscribe, send mail to [EMAIL PROTECTED]
with "unsubscribe hebrew" in the message body.