Jacinth is a red transparent variety of zircon used as a gemstone.

(Wikipedia)

Jacinth is a Swing component, based on default JEditorPane which is a common foundation for Java styled text editors. It is extended with convenient Actions framework and dialogs for text searching, inserting objects etc. Actually, Jacinth implements a complete and ready to use solution of a WYSIWYG styled editor which can be easily integrated into the Swing applications.

Jacinth includes a demo application (net.sf.jacinth.demo.App) – a simple editor which can create and edit HTML files in local filesystem:

Features

• Block formatting (P, H1-H6, PRE, BLOCKQUOTE, block alignment)
• Inline formatting (B, I, U, EM, STRONG, CODE, CITE, SUP, SUB, custom font/color style)
• Inserting lists (UL, OL)
• Inserting and updating images, links and tables with special dialog boxes
• Inserting special Unicode characters, rules and linebreaks
• Find and replace functions
• Unlimited undo/redo support
• Default clipboard operations
• Customizing editor look (text fonts, colors, etc) with an external CSS file
• Synchronized WYSIWYG and HTML-source modes

All editor operations are available as the Swing Actions, so it is easy to implement them in client application as the buttons and menu items (see the demo app for example). Also there are two prebuilt toolbars which can be displayed along with the editor pane.

There are no file releases yet, but sourcecode is available via anonymous CVS.

Problems

Almost all editor limitations and problems come from its parent – JEditorPane+HTMLEditorKit. In fact, this part of Swing libraries is based on ancient Sun HotJava and seems to be abandoned long time ago together with that browser. It is buggy, clumsy and intricated and there is a little hope that somebody in Sun would go to improve it now. So, if you are used to deal with modern valid W3C (X)HTML, you probably will be discouraged looking at your pages opened with Jacinth as well as at old-style clumsy HTML it produces.

Therefore, Jacinth is a rich-text editor component for Java apps, rather than a general-purpose HTML editor (except for very simple and straightforward HTML). Though, there is a hope that one day we will have an opensource implementation of a fully standards-compliant Java browser/editor.

Swing dialogs by default have no idea about “required” text fields, that is the fields which should be filled to perform a task. In this article I suggest a simple way how to automatically highlight the fields which have to be non-empty.

Our required fields will be highlighted when empty and switched to default look when a user enters a data into them. To track the changes of a field’s content we will use DocumentEvent/DocumentListener mechanism. DocumentEvent‘s are generated by underlying Document model when it is changed by some way. Listening to these events is more reliable way than tracking the user actions (such as key pressings) directly, because it is guaranteed that any content change (including possible changes made by program itself, pasting the clipboard content from a context menu etc) will be monitored.

To listen these events, we should create an implementation of DocumentListener interface:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

import javax.swing.BorderFactory;
import javax.swing.border.Border;
import javax.swing.event.*;
import javax.swing.text.JTextComponent;
...
 
public class HighlightListener implements DocumentListener {
 
    JTextComponent comp = null;
    Border defaultBorder = null;
    Border highlightBorder =
            BorderFactory.createLineBorder(java.awt.Color.ORANGE);
 
    public HighlightListener(JTextComponent jtc) {
        comp = jtc;
        defaultBorder = comp.getBorder();
        // Adding this listener to a specified component:
        comp.getDocument().addDocumentListener(this);
        // Highlight if empty:
        this.maybeHighlight();
    }
 
    public void insertUpdate(DocumentEvent e) {
        maybeHighlight();
    }
 
    public void removeUpdate(DocumentEvent e) {
        maybeHighlight();
    }
 
    public void changedUpdate(DocumentEvent e) {
        maybeHighlight();
    }
 
    private void maybeHighlight() {
        if (comp.getText().trim().length() > 0)
            // if a field is non-empty, switch it to default look
            comp.setBorder(defaultBorder);
        else
            // if a field is empty, highlight it
            comp.setBorder(highlightBorder);
        // ... more actions
    }
}

To add a highlighting functionality to a text component we should simply instantiate our HighlightListener with this component:

...
JTextField myField = new JTextField();
new HighlightListener(myField);
...

Note that HighlightListener constructor is parametrized with JTextComponent class, so it can work with any children (JEditorPane, JTextArea), not only with JTextField.

Our HighlightListener monitors the updates of a component document model and checks if the text is empty or not. If it is empty, it will be highlighted by adding a thin orange border:

Otherwise, the border will be reverted to its default look.

The code of HighlightListener can be customized for:

• Another highlighting method
• Additional highlighting conditions – e.g. we can check the content against a regular expression for required input format (valid email adresses for instance)
• Additional actions – e.g. to enable/disable the “OK” dialog button if required data is not entered.

Pete was at his computer when the phone rang.
— There are representatives of XYZ corp. here, — said Pete’s boss. — They liked our offers and want to sign a contract. Is it ready?
— Yes, it is. — answered Pete confidently. He had prepared the text of contract a week ago.
— Great, print it and bring it here, please.
Pete put the receiver down and opened the folder named “Contracts” in his “My documents” hierarchy. There were about two hundreds of files, but there was nothing with name about “XYZ”. He browsed few old subfolders of forgotten purpose and obscure names but found nothing too. Being a bit surprised, Pete opened the “Recent documents” list but it was full of newer files. The worst thing was that Pete couldn’t recall a name of the file. He even didn’t remember when exactly he had working on this document. Pete sorted the files in “Contracts” by date of modification, but there were a couple of dozens of files edited at the last week. “When it was? Tuesday or Wednesday or..?” He started to open the documents one by one and it took for about ten minutes. Nothing like.
Pete browsed the root of “My documents” folder (turned into a dump of useless trash for ages) and some other folders, where as he thought the document accidentally might be. Nope. He mopped his brow and loosened the tie. “I have to remember where I saved that damned file. Well, I came to the office, as usual read my email, then played Lines until the boss called me and asked to prepare the contract for XYZ. I took a standard corporate template for contracts and started to work. I had been interrupted few times for checking and answering email and once for lunch. I remember also that after lunch I worked around another urgent document, then got back to the contract and completed it before the end of workday…”
“The search! How could I forgot about it!” Pete quickly ran the file search and typed “XYZ contract” in the search field. He leaned back in the chair and started to look at the flitting indicator. On 16 minute of the search, the phone rang again.
— You should not hurry so much anymore. — said boss. — We have lost that customer.

Pete could not find the document and upset a deal.

This sad but edifying story might be a source of many fair conclusions. Someone would say that the Pete’s company needs CRM. Someone else would mind that Pete should spend less time to play Lines but more to keep his harddisk in order and so on. But I told this story not to show the advantages of enterprise automation and not for moralizing on such slovens some users are. This is a typical “use case” story of using a software tool. A tool that is in our way everyday.

This is a filesystem.

Can we ever live without it?

A hierarchical filesystem is a sort of fundamental computer concept which has almost never been seriously revised against utility, user efficiency and usability. Everyone knows that computers store data in files and folders. It’s a matter of course and it seems like a natural phenomenon, like air we breath and like the sun which rises on the East everyday.

Most of the “non-technical” people think that the filesystem is a necessary technological principle of a computer long-term memory. “Ok, if there was no another way, we have to live with it.” And producers of operating systems silently keep this opinion.

It is wrong. It is misleading. You are deceived. Everybody who more or less understands how a computer works knows that the filesystem has no relation to physical organisation of a disk memory. This is merely an invention of early OS developers who cooked that “convenience” once in the 60′s. There are no any “folders” and “files” inside the computer. This is a programmatic imitation, a phantom superstructure above real physical disk sectors and cylinders and there are myriads of alternative ways for it. The filesystem is not a necessary part of a computer.

What’s wrong with it?

My criticism is not against the filesystems as they are. I believe there is a number of excellent, fast and reliable filesystems with advanced security, journaling and many other useful features. They are doing their job and doing it well. My criticism is against the practice of providing filesystem as an end-user tool.

I’d be very surprised if I ever met some developers convenience or raw technology feature which became a good user experience. I’m sure the good things all come from careful studying the human’s tasks, goals and contexts of use. The task of “to store whatever” is too general to be succesfully implemented. It is nobody’s experience. It is a bare abstraction in hope of adaptation to the real world by the users themselves. It is like a software for “doing anything” which makes a user to define “what” and “how” to do. Sort of meccano, but not a tool.

Users usually have no task “to store” their data at all. It seems the only case is when they back their data up to DVD-R or to another archival media. Many of them even have troubles with understanding the “saving” and “loading” operations. I’ve written a document in the Word, isn’t it already in the computer? The knowledge of “saving” and “loading” files and of distinction between long-term and operating memory, between harddisks and RAM, is needless for users. It makes them to learn for unnecessary things and keep in mind a weird two-part model of a computer storage system. It has no relation to their tasks. It is in their way just because there is a bad design which is countlessly reproduced for 40 years without any improvements.

Try to invent an universal and intuitive definition of a “file” using no technical jargon. “This is a document or an image or an audioclip or a program or anything else…” Anything else what? “Anything what we can save to disk” — is only answer. It could work in the times when the disks (I mean the floppies) were an important part of everyday user experience. Everybody knew that data and programs were on the disks and the disks were the real tangible things. But many users nowadays have no idea what the disk is at all, except for CD and DVD (remember an anecdote that many Mac users have seen a hard disk first on new OS X icon) . The concept of a file is particularly technical and it can be defined in the best way simply as “a storage unit”. It might be useful in context of eventual data backup, restoring or transferring, but not for user’s everyday tasks.

Another weakness of filesystem usability is a tree-like hierarchy. The problem with hierarchical structures is that they have extremely poor scalability. They could work well for 720K or 1.4M floppies with few directories and few dozens of files, but now our storage capacities are thousands times greater. It is proven that usability of hierarchical structure falls exponentially with number of levels and number of items in them. In practice, a structure with more than even two levels substantially impedes the search of a specific choice. Creation of a good intuitive structure (e.g. a catalog) is a very complex task of information design which requires special recursive techniques such as prototyping, card-sorting, careful testing etc. The most of us in real life have no time and skills for that, so the structures we create ad-hoc today, become the dreadful puzzles for us tomorrow. And the filesystem provides us with everything to create those puzzles but doesn’t help us to unscramble them.

Outlook instead of Explorer?

New paradygm of personal resource organization should be based on a simple axiom: “Whatever a user does, she does her tasks on her projects.” A task is an activity to achieving specific goals using specific resources and tools. A project is a common context of more than one tasks. For instance, Pete’s task was to write a text of contract, his goal was to have the text completed and approved, the resource was the contract itself and the project was dealing with XYZ corp. This is a natural model of human horme and it should go out of scope of special project-management and scheduling software to be a foundation of entire human-computer interaction framework. These ideas were (in very roughly and initial form) implemented in the Memoranda project. I believe evolution of this kind of software will replace traditional file managers from their position of main user interface to navigate over resource collections.

It should change the way of everyday personal computing and make it more simple and natural. Instead of creating informal and often casual folder structures, a user would have a personal project-management framework for managing information resources as the internals of her projects. Resources are associated with tasks of the projects, so it would be easy to navigate and find them. In fact, it should be enough to go into the specific project context to get all related resources in the way.

It is not too futuristic. Though it seems rather hard to overcome 40 y.o. conventions, there already are the software which is passed through the files and folders and provide high-level, sofisticated and task-centered data structures.

E-mail clients, personal information managers (PIMs) and calendars working this way for decades. Many of the multimedia software provide their own media libraries management without obvious relation to the filesystem. For instance, working with my amaroK mediaplayer, I only care to put my new media files into a known single folder. The program monitors that folder and automatically updates the media collection, so I can easily find any song browsing the collection by artist name, album title, year, genre and so on. All modern Development Environment software (IDE’s) has advanced project-management tools for software development tasks including resources (sourcecode) management. At last, the Pete’s favourite Lines remembers the game score results and even if it doing so with files, a gamer doesn’t care about it.

Conclusion

…
Pete put the receiver down and clicked on “Dealing with XYZ corp” project icon on his desktop. In the list of tasks sorted by date he clicked the “Prepare the contract” item and the first thing that catched his eyes was the icon of the document in the resources area. He selected “Print” in the context menu and there was exactly 10 seconds since he had stopped to talk with the boss.

Somebody would object this is how an accurate user usually does with the folders and files. But why our software requires us to be so accurate and doesn’t help us if we aren’t get its high standards? Nowadays, the computers are smartest of the artificial things. And I’m wondered why they still supply us with information storages not smarter than a table or a bookcase.

I have a cranky idea: “Would we have to pay many thousands of bucks for CRM, ERP and other enterprise software functions, if our personal tools were a bit more sophisticated?”