Update

So I finished coding the CoreObject class and its working wonderfully. Finally some code I realy like which is simple and small. It took me a few hours to write which shows that designing code is the hard part, not writing the code. I am coding 'Saturn' which is a Shell explorer (without a programmer API and without virtual object support) that will show a few of my ideas like the Icon bar. By not releasing an API, it takes off the pressure of having legacy applications when I want to code 'Safire' (which is the full Screens experience). Saturn will allow you to view databases and records as files and folders, so you can see memos as actual files in a folder which should allow a more interesting ability to handle records of different types. It would allow you to able to view your records without your application. So bitmaps are viewable, text is opened with a notepad like application and forms can be created using an IDE and so on (dont know about the last idea...). This will show of the layering system which allows for movable windows with no flickering and the module based behaviour. Stay tuned (yes... this is another lets try again post...)

Update

Oh well, NDS wont allow me to post screenshots at the moment... I guess I'll have to wait a while to show you what I have been working on. If any of you were at the IBC 2005 at Amsterdam, tell me if you saw the mobile application working on the iMate or Dell Axim. I have been doing alot of code design and writing lately, messing around with the object store. Hopefully I can get the object store finally working in code. Its design is smaller and simpler than ever but also faster. I learnt alot being around NDS Employees including alot of C++ code experience. Writing the layer design into the NDS MobileEPG was very good for Screens, since it allowed me to prove to myself that I am able to do this Screens Environment project. I also learnt the problems with my design, so I wont have those issues in Screens Environment. I guess my blog is kind of an island at the moment, however, maybe in the close future, users will flock to my blog and read this post ;) I am currently coding the Item class which is the Object class without the method capabilities. I hope to finish the Item class by the end of this week. The hardest part of Screens Environment is to agree on things. Any time I have multiple paths to choose, I start scratching my head of where to go. I used to talk alot via MSN Messanger however once users lost interest, that sort of lost its use. Oh well... Alone again...

Single Object Store

I have just been watching for over 2 hours the PDC 05 Event from the Microsoft Web Site... cool stuff this Avalon... um... Windows Presentation Foundation. Those 3D effects are realy smooth ;) But then they start with Data... This LINQ stuff might sound good but its just adding another headache for developers, not removing it. Developers have to deal with so many API's and although they are trying to add yet another single API, they are just adding another beast to the collection. There are so many data sources we deal with... from tables to file systems to the registry to file internal data and so on. What is needed is not a WinFS single store but rather an API to merge all these sources into a single design API. I dont care about that registry folders are called Keys and that registry files are called Values. Just give me Folders and Files instead of including new concepts. Here is the rant: If I write an application to use the registry but then I am told to use an INI file (so that the settings can be shared on a server). Think of the amount of not only API but logic that needs to be changed to make this work. Although they both are using the key and value design (just INI files have only one key depth), I still need to use a different API. Dont think this rant is just at windows, PalmOS does the same thing! Instead of having a single database API, I have three API's to handle! The data manager, The resource manager and the VFS manager. If I want my application to read documents on the card instead of from the internal drive, I need to recode all my calls to the data manager when they have exactly the same ideas. This is one of the reasons I have been working so hard on the Object Storage. Its not about adding meta-data but about abstracting the meta-data we already have. I want a single API with minimal changes works for both the memory manager, VFS Card, Databases, Files, Serial port, Bluetooth and the list goes on and on. Instead of calling a function like: SetDeviceID, I want to browse the IDs and select the one I want using a hierechy design. Give me Folders and Files everywhere! I want a device to be a folder, I want a document to be a folder holding the documents elements. I want a serial port to be a folder which any data I put in is sent over through the port. I want to create 5 files with data and send them all off together easily without fiddling with data buffers. This frustration is what is driving me forward with the Object Storage. I want a single abstract design which will spare me the details and allow me to do things in a 'virtual' way.

Screens is still alive (or at least its concept is)

Hi Everyone, or anyone who checks this blog for life signals, My boss is at the IBC at the moment, so I am stuck at NDS a bit bored untill he comes back and gives me lots of work to do. Untill then, I have some spare time to actually code Screens at home. I just upgraded my RAM to 512 MB which should realy help when coding in PODS because before hand I only had 256 MB and PODS was so slow. I used to use Falch.net but they want down under. So finally it will be a joy writing lines of code without my CPU having to catch up (PODS uses Java which is why it has a hefty RAM requirement). I have been doing alot of research as usual and I still (I dont know if anyone has) haven't solved the problem of the store island which is how to import/export additional meta-data that cannot be stored with the original file. Untill I solve this, I wont be able to make the object storage. So instead, I'll spend time on trying to build a design without the object storage. This means that you wont able to attach contacts to mp3 files. I realy wanted this feature... oh well... I might find a work-around or maybe with a bit of luck solve it. I have noticed quite a lack of products in the area... iSpin seems to lack updates and WinLauncher is looking a bit old as well... is there anyone working on some secret release or is just no one interested in these kind of products anymore. PalmOS seems a bit dull lately apart from selling companies back and forth and new devices here and there. About the only interesting thing I receive from the PalmOS world is Jeff Kirvin ;) If there isn't an object storage which has been the number 1 reason for the lack of Screens release, is there anything you would want instead? Please post here or email me a list of your wannabe features. I am going to start coding next week again after a break of a few months (of coding that is). There isn't any point explaining why its so hard to create an object storage (just read WinFS's problems and I share them as well) but maybe an OS without an object storage is not that bad after all.

Still going...

Sorry for the lack of posts, I have been working hard at NDS and it looks like they might keep me after all (keeping my fingers crossed). I actually used a few of my Screens ideas (like the layering system) in the NDS project and the managers are realy happy with them. Its actually been great for Screens because it allowed me to test my ideas in real code and find all the inconsistencies and just make it better. It also allow me to know that my designs are implementable and that they work. Cannot show you any screenshots because I am under NDA but I have been told that the EPG is cool! You can come to the IBC 2005 at Amsterdam (sep 8th-13th) to see the UI I made for the Mobile EPG project. It can actually run live TV now on a iMate PocketPC. I am making changes this week so it will work on the Dell X50v (because its 640x480 VGA). Here is a little document I wrote over the weekend which describes the Screens Environment Kernel. Enjoy! (5 pages long) http://www.geocities.com/zhamilton1/ScreensEnvironmentKernel.doc Tell me what you think about it...

The search for storage Part II (Editorial)

Part II: Default Consistency In part I, I talked about that the object storage needs to be simple if it wants to even be implemented, not even talking about using it. I do alot of research and here is one of the articles called "The Anti-Mac Interface" http://www.acm.org/pubs/cacm/AUG96/antimac.htm which goes over alot of issues but the one I want to focus on is consistency. While complete consistency is quite impossible if the storage is going to be useful (if it was totally consistent, there would be no such thing as links because deleting an object would always remove its data) but thier are basic rules which are needed to be kept especially in the removal area. Having removing an object in one place, removing it from another does not sound like a good idea and many times I have created a shortcut to a file instead of a copy just to find it out when I delete the original. Ways to solve this is by using references where removing the last reference, removes the actual object. The problem with this is that current reference designs are very limited where links are either included in the reference count or not. WinFS is built this way and its not even released yet. The reason this is a problem is just a plain idea of categories. If I put references to a document in multiple categories and I want to delete the document, I dont want to have to remove it manually from all categories. A way to solve this is by allowing objects to list thier references and then just remove all references, but then you have lost the whole idea of references in the first place which is to allow data to exist in multiple locations shared. So you need a way to have references to references where you can have basiclly a tree of reference points so deleting the last reference of the original object will delete all the child references. The problem with this is that its not very consistent. Why should it be? That is exactly what the Anti-Mac article talks about. These known things like "the user should be in control" or "Metaphors" are what cause problems with this design. If I reference to a reference which references to a reference which references data, doesn't this sound a bit complex. Well yes... but I dont normally need this depth of referencing anyway but it would be useful if the time came up. How has this got to do with consistency? Not much... just kidding... The thing to understand here is that sometimes consistency can limit you. I am not saying that things like the OK & Cancel buttons should have different positions in different dialogs, I am saying that consistency should be a default, not a forcing rule. Think of it that consistency is the way a bar of metal should be, straight and strong but bendable if needed to be. This comes to the first word of the title of this editorial which is Defaults. Defaults are a very powerful feature. It allows a normal user to use an application or system and feel that its small and comfortable but if he wants he can unlock the power of the system when he needs that power. Users dont like modifying techincal options very much. They might do some tweaking for performance sake but most of the time the options you want to modify have a look & feel written all over them. These should be the default options displayed consistently throughout anything. Dont tell me I need to enter a port number if you know the one to use in the first place. I might want to use a different one, but since 'I might' is less important than 'I mostly use', the default should be non-technical options which make changes in the way I work, not in the way the computer works. This design should be applied to the file system as well. I dont need to care about providing a 'save' name to every document just because the file system is dependent on it. Names should be optional. If you are dependent on some unique name, create one yourself and allow the user to change it LATER IF he wants to. The same goes with the documents location. Dont force the user to search for a location if you know the most common one to use. No, Its not the last used location because probably I chose a different location because I made an expection, not because I wanted to make it the default next time I save a document. It drives me nuts when I save a new document on a floppy but next time I save another new document, it shows me the floppy to save it in! Floppy is a temporary storage and you dont create multiple documents just to save them to the floppy and if that is the matter, allow the user to jump to the last used location but the default should still be 'My Documents' or such. Defaults can be a great factor if a user is happy or not. Before you prepare to make a user make a decision or choose an option, think about if it is realy and totally neccessery to ask him. Its like these installation wizards which most of the time you press next, next, next, next, next and another 7 times next just to install a product where it should show you a single finish button with a great button called 'Options' on the side. Now wouldn't that cut the need for a wizard just to install applications.