ODC,
Thank you for getting serious about the issue. The reason I named names was exactly to point out "ease of use" as being the key (the other two are obvious requirements), and to suggest that designing for ease of use is a separate art/science combination that most developers know so little about. For this reason, I am against too much implementation-centric approaches most developers take.
Did you read part one of my story? I hinted that ease of programming forced the solution (Iran System vs Sayeh) that was less user friendly. The current bad implementations of bi-di text editing are exactly the result of thinking about ease of programming instead of ease of use. Many developers claim a solution is not implementable because they are too lazy or incompetent to implement it. So, I usually leave out implementability as a "principle" to eliminate an excuse for poor designs coming from lazy programmers.
In "ease of use" section you put a few requirements that actually skip the initial principle design, the items you listed will be the output of one of the design phases and may be altered repeatedly as the overall design iteration progresses. Note that designing for ease of use is highly experimental and iterative. The four step approach that you propose misses that fundamental point. Ease of use is a philosophy or goal, it does not give you requirements. The art and science of how you translate ease of use into an implementation design is not well recognized and formalized among software developers and it usually doesn't get its due attention.
To better illustrate what I am talking about, I like to replace "4) Test the implementations" with "Perform user testing and go back to the drawing board it it is not working for the users.", As a result, "3) Implement the designs" also becomes "Build realistic user testable prototypes". See, I am talking about a different phase before usual software design and implementation. The last working prototype from that phase is the software design [1]. You'll take that design and create an implementation detailed design for each target platform or GUI tool-kit. Next comes the usual implement, test and optimize iteration. I emphasize optimization because any system/library/service-level software which will be used by many other software components needs performance profiling, tuning and optimization. The current bi-di implementations are very weak in this regard and create performance bottlenecks.
- Hooman Mehr
[1] A design that can produce end-user testable prototypes tends to be implementable.
On Jun 10, 2004, at 6:38 PM, Ordak D. Coward wrote:
Hooman,
I agree. However, I need to clarify a few things. I like a design process that is based on principles. Here are the steps (of a design process that I like):
1) Lay a few underlying design principles.
2) Try to come up with designs that follow (if not too closely) the principles.
3) Implement the designs.
4) Test the implementations.
Of course, there are many important issues that are missing from the above picture, mainly the fabric of the design group, or in other words how the design group is shaped and works.
For this specific design, here are the main principles in order of importance.
- ease of use The design should consider a wide variety of users. e.g. users who are introduced to computers and bidi text input at different levels. At one end we may have people who are using a computer for the first time and cannot read Latin characters; to people who are so used to mo-di (as opposed to bidi) text input who like to see exactly the same semantics at work for bidi text input; to people who have no problem with the current bidi input system(s).
The input semantics hence should try to accommodate all these users. The semantics that work for me as a user (versus a designer) are: o Keystrokes should have a visual effect on screen. - I should be able to see what I have typed so far. - I like to see all control characters when typing as well. o Cursor, or in general, visual cues should provide information to me on what happens when I enter certain keys on keyboard. \footnote{A design may implement two cursors when the (visual) position of the next character is not unique} o Arrow keys, I like the arrow keys move in visual order.Even if that means I cannot place the cursor between some characters. o Pointing device should allow me to perform functions I am used to currently, like selection, copy+paste, and moving the text insertion position. o Selection, I like the selections to be continuous looking on screen. In case, the selection looks fragmented, I like to be forced into selecting a bigger part of text that is not fragmented.
- implementability The design should consider the limitations of current platforms. For example, the design should assume the input devices are a pointing device and a standard keyboard, and the output device is a small area of the screen. The designer should also consider implementability of the design inside current platforms.
- completeness. The design should allow to the user to input all possible bidi texts.
On Thu, 10 Jun 2004 10:53:43 +0430, Hooman Mehr <[EMAIL PROTECTED]> wrote:
Also, note that this issue is one of the single most important issues we need to solve in order to make using computers as easy for bi-di users as it is for Roman (or Latin) Script users.
There is a lot of depth to this issue, don't try to come up with a quick idea and immediately think that you have solved it. It takes an expert in human computer interaction design. Someone in the same class as experts like Jeff Raskin, Bruce "Tog" Tognazzini, Donald A. Norman or Jakob Nielsen. Even then, we need extensive prototyping and user testing to refine the solution and select the best alternatives.
Alright, I know, we don't live in an ideal world (or Iran) and we really can't expect to go after this issue in a really systematic way, but lets try to deal with it the best we can.
- Hooman Mehr
[1] If you have missed that post, look for "Persian GUI Design Specifications & Guidelines" in the list archives.
On Jun 9, 2004, at 3:01 AM, Ordak D. Coward wrote:
Please ignore this while I can successfully prepare a long e-mail with
gmail :(
On Tue, 8 Jun 2004 17:08:53 -0400, Ordak D. Coward <[EMAIL PROTECTED]>
wrote:Following up the old thread, here is my attempt to understand the problem. We may then agree on a desired behavior, and then on an implemenation.
The problems appear when typing a text in a BiDi enabled editor. it seems to three categories of concren.
1) When typing a bilingual text, the cursor jumps unexpectedly. An example, is when I type "HERE IS SOME RTL TEXT", (where UPPERCASE stands for RTL characters), in notepad or any input line, the cursor (denoted by |) and text appear as follows: | |EH
_______________________________________________ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
_______________________________________________ PersianComputing mailing list [EMAIL PROTECTED] http://lists.sharif.edu/mailman/listinfo/persiancomputing
