User Interfaces

Brief Overview

What a user interacts with - i.e. what they see (or hear, or feel).

API problem

Traditionally, whenever a programmer wanted to create a program that interacted with the user (being by input and/or output) they had to write their program specifically for the system they were using. On a Windows machine this would mean writing to the Win32 API. However, if they then wanted to port their application over to MacOS, MacOS X or any of the X-Windows toolkits, you would have to completey re-write all parts of your application concerning the UI.

Web Applications

A lot of people got sick of writing the same code 5 different ways each doing exactly the same thing, but looking slightly different. A lot started to create "Web Applications", a combination of client-side HTML, Java and JavaScript and Server-side languages such as Perl, PHP, ASP, VBScript and Python. The main problem with this solution is that everything is a hack.

The HTTP protocol was purely designed for serving static documents (later extended for dynamic documents using CGI), HTML was purely designed for the markup of documents (Hyper Text Markup Language), JavaScript was a hack to get some extra functionality out of the two and anyone who's had to deal with "Session Management" knows exactly how much of a mess things can get.

A Solution?

So what about developing a way of "Write-one Run-many(places)" but for User Interfaces? Well, it's a good idea. It's also what some other people have done (in one way or another).

Java and its SWING API is the most prominent of these. SWING will allow you to code your Interface (in Java) once and have it displayed using the "Look-and-feel" of whatever platform the program is run on. There are several problems with this though:

• It has to be written in Java (i.e. no Perl)
• It's not networked (unless you code your interface and application seperately and invent your own protocol

What needs to be displayed?

A User Interface (duh). But what does a User Interface consist of? For this project, we're going to narrow the field down and primarily think of Graphical User Interfaces (GUI).

When you observe current programs with a GUI. Such as an Email program, an instant messanger and an mp3 player the interfaces are fairly constant. That is, nothing radically changes too often while the program is being run. In the MP3 player, you change the time, the track name, and maybe add/subtrack items from a playlist. In an Email program and instant messanger you have message windows (which are all identical except for message contents).

INSERT IMAGES HERE -- when i get the 5 mins to convert them....

What Needs to happen?

We need to be able to do several things:

• Create a GUI (add elements)
• Modify the GUI (add/modify/remove elements)
• Delete Elements

When does it need to happen?

• Create items - on load, on user event, on program-specified events (i.e. every second, on database update, on cd insertion)
• Modify Items:
  • On user input
  • On program-specified events (i.e. every second, on database update, on cd insertion)

How can we do this?

• A protocol with 3 main functions - add, modify, delete.
• A method of accessing existing elements - some kind of object heirarchy
• Some way of adding elements of a 'type' (such as button, menu) consistently

Why a protocol?

Because of the need for program-specified events, there may be a lot of 'chatting' between the program and the UI server. Even though the up and down streams of data are probably going to be pretty different

Creating UI Elements

It's pretty simple to think of what can be implimented:

• Windows
• Buttons
• Menus
• Text Boxes
• Icons
• Pictures
• etc.