IKANGAI Solutions. e.u.

Mobile Business Solutions

T F G+ E

Posts Tagged ‘Text Editor’

#EOF

February 26th, 2012 by Martin No Comments

In a recent CACM article the authors Kai A. Olsen and Alessio Malizia argued that modern mobile devices should allow user to work with files, to let them experience the technical aspects of their devices. This – according to the authors – leads to informed (and empowered) users that know how their handle their data and are able to control their data; given that all devices can be mounted as external filesystem.

However, the file metaphor is more and more disappearing on devices like the iPhone or the iPAD. The data of users is sandboxed within apps and users can only access their data through their apps. This approach hides files from users, making the file metaphor obsolete. I his book “you are not a gadget” Jason Lanier also argues that files should be a thing of the past:

The file is a set of philosophical ideas made into eternal flesh. The ideas expressed by the file include the notion that human expression comes in severable chunks that can be organized…and need to be matched to compatible applications.

I fully agree to get rid of files. But, and that is the catch with the approach of getting rid of files, vendors like Apple use this as excuse to completely lock in the user. Users get their space on Apple’s iCloud servers and Apps upload the data of users to the cloud. All this happens transparently for the user: the user has no access to files and thus looses the control over the data. This is also pointed out by the CACM authors as main danger of getting rid of files. Again, I fully agree. But their approach of keeping files is not very attractive, because the file concept after all goes back to – in terms of computer science – ancient times and is a concept backwards.

I propose a two level approach (a big thank you goes to Christian for the input on this idea). First of all, users create their own stream of semi structured data objects like text, video, audio or even small programs. This is the content reservoir on which the user later operates. Each of the semi structured data objects must provide a standard way of accessing them, preferably in a manner so the user can share these objects easily with others. After creating the content, the user can organize it “semantically” and add it to the stream again, thus creating a stream of hierarchical mashups of the content.

In doing so, I make use of a diary metaphor that lets the user create a stream of diary entries. These entries (pages) can be combined to new pages and added to the diary again. I’m putting these ideas to a test with my ongoing editor project for the iPAD which should be completed in the next weeks.

your ikangai team

Searching Invisible Things

January 16th, 2012 by Martin No Comments

Users are often confronted with “invisible things” when using a technical device like a computer. A typical example for invisible things for users is meta information about files. This data is hidden away from the standard user (not from us geeks), because it is widely considered that users do not need to know the permissions of a file, i.e., whether it is hidden (Windows) or the file’s attributes are 644 (Unix, Linux, MacOS).
Attributes can also be set for smaller things on computers, such as paragraphs, words or even single letters. However, setting an attribute of a text, has an effect of the text that can be observed by the user. For example, if a text is set to bold, the user expects the text the be rendered bold.
But there is a class of data that is not directly visible to the user and nevertheless is very important to the user; it can be even distracting when permanently on display. The class is data which describes data on a different level – on a semantic level. To give you an example:

The blog entry that you are reading now discusses meta data and how to display it in an iPAD App (an editor/notebook) to make it easy for the user to handle and manipulate it.

In the example, the sentence describes the content of the blog entry on a more abstract level – it is meta.
In my current project (the ideal editor/notebook for the iPad) I’m facing a problem that is closely related to invisible things. More specifically, I’m wondering what to do with tags that a user can give to portions of text to make the retrieval easier (and faster). Since tags are not per se part of the text, they are obviously meta data – they are about the text. Furthermore, tags may be given a posteriori (after the text was entered) to classify of the content. This kind if data is also called folksonomy. So, if you write your text, where do you display this data? Or, do you even display the data at all? But, if the data is not visible, how can you search for it? In my case, I’ll experiment with displaying tags on a separate window and displaying them when the text is being scrolled. The search for tags will be handled in a separate window as well, because it is difficult to handle search for different semantic concepts in a single search box without confusing the user. After all, even if tags are not part of the text, tags can appear in the text. This makes the decision complex: where do you jump to? To the part of the text that is marked with a tag? Or to the tag in the text?

your wondering ikangai editor/notebook development team

Searching in a Text

January 4th, 2012 by Martin No Comments

As promised in one of my last posts, I will discuss the issue of searching in a text. As with the cursor, it seems fairly easy at first: just jump to the position of the text that is searched for. But if you think of this activity in more detail, you will notice that jumping to a location is not unproblematic, because it is directly connected to the search direction. So, in which direction should you search? Up or down? This is a priori not clear and many programs offer the simply a choice to search upwards or downwards. Other programs highlight all occurrences of the text that is searched for. The latter has the effect that large portions of the text end up highlighted if you searched for a common word and thus makes you search in the highlighted text again…
When I was observing myself, I realized that I am typically looking for the nearest occurrence of the text I’m looking for, in relation to the current position of the cursor. I do not care in which direction the direction the search goes, I simply look into both directions. And after a bit of trial and error, I eventually figure out in which direction to search. As long as I find the text I’m looking for, I’m happy.
Now, when I write a text on the iPad, I’m somehow expecting the tool to do the same; in a first step I’m only interested in the nearest occurrence, independent of the search direction. Then, I decide in which direction to search. And this is exactly how I’ve implemented the search for my editor/notebook on the iPad. It marks the nearest occurrence in the text and then the user can decide to search upwards or downwards.
Another minor, but important detail is an indicator how many hits you can expect when searching into a particular direction. This helps the user decide for a particular search direction.

your ikangai development team

PS: This text was written with a early beta version of my editor/notebook (of course ;-) ).

Labels

January 2nd, 2012 by Martin No Comments

Labels are very common: almost every icon has a label that explains its meaning. If you think of it, this should not be necessary: icons should be self-explanatory. After all: a picture is worth a thousand words.
However, in reality it is hard to find icons that are self-explanatory. If you are a Mac user, take a look a the icons in the dock and wonder about their meaning Which of them explains itself? Some of them do, like Mail or Calendar. But what about a CD with a rocket symbol or a compass? The former represents the Launchpad, the latter Safari (which happens to be a Web Browser. Yes! Even names can be difficult to interpret).
It seems to me that icons are an artistic expression of the designer rather than means to transport semantics of a program. This makes sense, because there is a label that explains the meaning. Now, if you look at the position of the label, you will mostly find labels below the icon. Again, this is perfectly ok, if you point to a label with a mouse or a pen. But what happens, if you use your finger to point on an icon on a touch screen? Then, you obscure the icon and its label. This does not happen with a mouse pointer, because the it is smaller than the icon and you still can read the label of an icon if you position the mouse over the icon.
The solution to this problem is to position the label either above the icon or to redesign the icon in a way so that the user cannot obscure the label. This is what I try to achieve during the development of my iPAD editor: I’m experimenting with the position of labels and the design of buttons to make the App easy to use for everyone.

your ikangai user interface design team

Text Editor Design Considerations

December 30th, 2011 by Martin No Comments

I’ve made progress in the design of the text editor for the iPAD. One surprising complex issue concerns the incremental searching of text. At a first glance, it seems to be straightforward: just enter the text in a search box and scroll to the corresponding text in the document. But, what to do with the text cursor during the search operation? Should it remain on the screen, to remind the user where the search has started? I’ve experimented with two options: (1) setting a cursor to mark the origin of the search or (2) removing the cursor from the screen (which appears to be widely adopted in editors). In my opinion, the first option has the benefit for the user to be able to continue where he left if searched text could not be found in the document. This corresponds nicely to a workflow that is interrupted by a search for a text that if it is not found in the document resumes its activity where the user has interrupted his work.

A related issue is the search direction. Again, there are two possibilities: (1) search towards the end of the document or (2) search towards the beginning of the document. Here, we need to look at the current cursor position – if the user is at the end of a document, an upward search makes sense. However, if the user scrolls first into the middle of the document, then the user has already a rough idea where to look. In this situation, searching upwards is as good as searching downwards. My initial idea is to present the user simply the possibility to decide on his own. But, I’ll give this thought to this interesting detail and write about it in my next blog entry.

your ikangai text editor team

Designing a Text Editor for the iPAD

December 28th, 2011 by Martin No Comments

What functionality should a text editor have that I would use on an iPAD? This is the first question that I had in mind when I started to think of a text editor for the iPAD. At first, the functionality seems rather obvious: create file, edit text, save file. Spellchecking would be nice. And Undo/Redo. Well that’s about out. But when I read The humane Interface by Jef Raskin, I started to think: how do I use a text editor? Is it a replacement for a notebook? And that was the moment when I realized that I wanted a notebook that has a build in text editor.

In my notebook, I’m writing down ideas, sketches. Typically, in no particular order other than the order given by the paper notebook interface: time. I divide my content with lines and write down the date of the note. That’s it. Plain and simple. With my favorite text editor on my MAC (TexShop) this is a different story: I create several files (like the one in which I put the notes of for this blog entry) and store them all over the place: sometimes on the desktop (because I want to continue later on this and want to keep it “nearby”), sometimes in a dedicated work directory hierarchy. However, sometimes I just forget where my notes are and I have to search for them with Spotlight.

These experiences (and Jef Raskin’s book) made me think. If you look at iOS, you won’t find files. The file metaphor (ever-present on your desktop) simply does not exist on mobile devices with iOS. Instead, you get an App and the App handles your data for you. This makes perfectly sense: what you need is DATA, i.e., the CONTENT. The iPAD editor does exactly this: you do not need to handle files. To find your data all you have to do, is to enter one or more keywords and jump (leap) to the position in the text. The beauty of this approach is that there are no files – you do not need to remember in which file you saved your data.

your ikangai development team