Double Design Direction

I am starting to feel like all these kernal programmer hobyists who feel like they are coding in the dark. This is not the way it's meant to be... I dont want to end up like all these 'dead' projects so I have decided to attack the problem directly. I will be coding from bottom to top (core to visual) like I have done untill now but at the same time code from top to bottom (visual to core). How is this possible? By seperating the graphics component from the object design it can be faster, bare-bones and allow me to make a 'mini-ui' to test the components that untill now have not been tested because I had nothing to test them on (walking in the dark). The graphics component (ScrDraw) and the text component (ScrText) will allow to draw directly to the display without any need of off-screen displays and the like. This seperation does not in any way remove the UI functionality that I want... actually it improves it by only making 'static' UI controls (buttons, lists and windows) using the layers component (based on the object component) while dynamic controls like progress bars, game views and animations using the draw component (no dependency). This will also allow me to finally give you all some visual progress on what's happening. I will able to post the 'testing' UI to show you all I am actually coding and not wasting my breath. How long? I have the system draw functions coded. I still have the text and generic functions like the mini-UI API but I should finish this by the end of the week. Then I can test the code of the first component (storage) and continue working on the memory component. I will publish the screenshots of the test UI as time goes by so just wait a bit more. I will be mixing between a CLI (Command line interface) and some graphical capabilities for the test user interface. This has nothing to do with the final UI and is for testing the core components only. If any of you have some ideas for the temporary UI post in the comments... I am always open for suggestions of any kind.

Memory Component

Good News... the API's have been locked (not modifyable untill the demo is released) and the first component has been coded. I am now working on the code of the second component. The second component is the Memory component. The memory component takes the stream that the first component (Storage) supports and breaks it into blocks. Each block is a memory allocation which is created in the stream so it keeps throughout application launches and soft resets. The header of each memory allocation is stored at the end of the storage stream. Header = StoreSize - 1 - (Index * HeaderSize) The '-1' is to get the last 'address' of the stream which is always '-1' because the address is zero-based. The number of header entries is stored in the first 4 bytes of the stream. The data of each header is stored between after the 4 bytes and the last header entry. The memory component works in an 'add-only' design. This means that if you remove a memory allocation the header data pointer is NULLed to specify that the entry is empty. No moving of allocations is done and new allocations are always allocated after the last allocation (if the last allocation was NULLed then the new allocation is written after the last 'valid' data). This allows for no moving at all of allocations in normal use. When does the system realign itself and gain all free space? When data is written and it will overrite a header entry (the data has reached the header part of the stream). All headers are compacted first and then it checks if it fits. If not it realigns all allocations. This might look like a large proccess but a few things remove the problems of this: 1. Data is only ever moved once in the realign. This is because everything is aligned from start to end. 2. Most realigning is done at the end of the stream since many of the allocations dont change thier location. 3. The Screens Environment automaticly aligns what it can when the device is turned off (mantience mode). This happens very quickly and even if you turn on your device in the middle, it stops aligning. This might sound a CPU kill but if implemented correctly the user might never actually see a single align message if the user turns his device off many times a day and the stream is big enough. The system notifies the user if the stream needs to be made bigger. If any of you have questions... post in the comments and I'll 'edit' the post to answer your questions. Hopefully I should finish coding the component quick so I can work on the object component (the hardest component of all).

Reply to Icon Based Menus

First of all, thanks for all you users who posted comments on www.OSNews.com it was very helpful and allows me to get this project done faster. First of all I did not know it would catch on that quickly... Icon based menus I have not seen in any current or old designs. This is not a toolbar or the OSX Dock. It slides and is not static. About the icons, you are all right... just blobing some icons wont get the job done but has to be thought about carefully just like any toolbar icon. Many icons have done well and are recognized by most users very quickly. I am a user perfectionist when it comes to small details. I can go through entire applications pinpointing problems. I once gave a company multiple emails of about 83 changes/fixed/ideas to implement and they did implement most of them. Just like the OS X dock has not been such a huge hit because of it's usability problems (the icons move without users doing so and thier order is not preserved) and my idea does not suffer the OS X dock problems because it only moves when the user moves them. This is why it can be spatially browsed. The user makes the changes... just like we remember where the light switch is, even if we do leave the room it's because it only changes when we change it directly. The icon based menus are not displayed at all times but rather are a popup when you tap a button (or the 'Go' button in the future Screens Environment). And you would not be browsing all your applications from a single swipe but rather it would be categorized and you would browse categories. It just makes it easier when the mouse/pen dont have to move all over the screen (i.e. Start menu) just to get an application/document running. This is why it has to be navigational browsing and not spatial in the way of 'windows' because thier is no point for location memory here but only position memory. While using them for actual File/Edit/View menus will have to see in the beta testing, the launching of applications, recent documents, settings and so on will be in the icon bar for sure because of the speed it allows you to get to a certain object once you know what you want (i.e. Applications->Games->Cards->Solitare) and if you dont know where the object is... no matter... just tap the edit box (dont ask for mockups... I cant do them at the moment while the code is not done) below the icons and write letters to show the results in the icon bar. Then you can just sway left/right to find the object you want and it will tell you where it found it. This method is a bit like alt+esc with alt+tab mixed together with some extras. Although I did not know about alt+esc (thanks for the tip) it has similar capabilities but with a quicker way to activate windows. When activing windows in the icon bar, you dont have to actually tap the window you want but rather only the thumbnail in the center gets it's window brought to the front. However if it leaves the center, the window returns to it's original stack order. Only a window which is tapped on (therefore hiding the icon bar) gets it's window to continue to be on top. Also the icons would not be applications specific but more general. I dont know about what to do for the application menus but for windows it would be thumbnails and for applications thier icons and for documents also thumbnails with a miniture application icon on the bottom right. When I mean icon based menus, I am including text in the idea. Without text you would all be right to say the design sucks (i.e. MacOS Dock). Text would be used to identify the icons but afterwards you could identify the icons much quicker. How many times do you actually read the word 'Back' when you are browsing back/forward using the IE toolbar buttons? Very rarely. The idea might sound corny without any mockups but I did not intend for it to be a 'wide-scale' article just a thought of mind. When I finish the layers component code, I will able to show you real animations of the thing working since the icon bar is one of the first UI parts I need to code. BTW: I just got married last week which is why I dont have much time on my hands ;)

Icon Based Menus

We have all used menu bars in every operating system. This has been the same since the original MacOS and has been copied for every other operating system without much differences apart from its location. MacOS has a single menu bar while windows has a menu bar for each window and the menu items themselves. Apart from that, nothing has changed. Menu items are still displayed horizontally and drop down vertically. Its still hard to get to sub menu items with a quick dash of the mouse without it disapearing. This has been one of the most unchanged parts of the desktop metaphore. It's time for a change. How? We have been using icons also from the first decade of GUIs, so why not apply the same for menus? But icons are big and menu items are small. Thats just the problem... menu items are too small. When menu items are stacked in a vertical manner, this makes it hard to select a menu item without missing it sometimes. If its a list where a mistake is not a problem, menu items do actions and tapping Print instead of Save makes you having to rush to the task bar to cancel the print job is not exactly user friendly. And dont think of seperators... this would just look worse. One of the problems with icons is because they take alot of screen space, it's hard to scroll them. This is what can be solved to make it usable. Imagine a film strip... it has loads of pictures seperated from each other. Place it aligned horizontally to the bottom of your display and imagine every window on your desktop has a thumbnail in the film strip. Slide the film strip left/right (moving the film strip but keeping it aligned) and see how the thumbnails move off-screen while others come on-screen. To do this inside the user interface, you would just drag the mouse/pen left and right to scroll the film strip. Now imagine that the end and beggining of the film are connected which means that scrolling all the way left will return you to the original set of thumbnails on-screen. Tap on a thumbnail would be just like tapping on a menu item and because menu names could fit in under each icon you get a big target to tap, an icon to identify with and text to attach to the icon to learn the icons identity. Because only a specific set of icons are displayed on-screen at any time, it looks less complex then 15 items on-screen even though with a single drag you can get to them all (left/right). How to do sub items? Easily, tapping on a menu icon which is a sub menu (it has an arrow next to the name of the menu icon) navigates to show only the icons of the sub menu. How to get back up? Tap the back button below the film strip. Wait a second... this sounds alot like folder/file browsing? what's the difference? The difference is the way you scroll allows you to bring folder/file browsing as a menu experience. We use so many icons per day why not memorize some more. You could still allow users to use existing menu design but allowing them to experience this by default. I dont see any major OS's doing this untill someone else has, so I am going to do so with Screens Environment to see how well users like it. Just to give you a major reason why I will be using it? For window clutter. I believe that this could be the key to stop window clutter since I will use 'spotlight' on the center icon of the strip. What does this mean? This means that if an icon reaches the center inside the spotlight, it's window representation is brought to the front of the display. If it leaves the spotlight it returns to it's existing location. This would allow with a single stroke to switch between 3-8 windows depending on the number of icons on-screen at a single moment. You could find the window you want by it's true representation instead of a title (windows), icon (MacOS) or shrinked representation (MacOS - Expose). It would feel just like flipping through pages in a book. We have done that for centuries, why not apply that in window searching. Many guidelines say dont include more than 6 items per menu. In todays requests of features that's nearly impossible and ends up in either too many items per menu or too few features. This has never been the case in icons and therefore has no problem in icon based menus since the number of menu items the user sees are less than 6 but the number he can get to is more. What developers/user designers can do is put the 6 icons that a user sees when he first activates the menu is the most common and leave more advanceed menu functionality in a scrollable reach. What about menus which items can be tapped and have sub menus? That should not be the case. Make the 'default' sub menu item centered when the user taps on the parent menu item. Remember though that text is still under each icon. Learning icons is harder than reading text so text must be there (not via tooltip) for such a design to be successful. And keyboard shortcuts also still exist because of the text. Also note that the icons must be simple enough to understand which is a tricky part but could probably be done if spent alot of try and testing. And this is NOT a toolbar. It's a film-strip. What's the difference? Toolbars are not scrollable while film-strips are. You can drag & drop icons to move them to your own order (every user and thier preferences). This design is not perfect and is just an idea without any working models behind it. I will post a more updated version when I can finish coding the components required for it. Of course this theory will have to prove itself in the beta testing of Screens Environment... but it's a thought worth thinking about (in my opinion).

Object Storage (Editorial)

You hear about storage systems alot in the news, reviews or even blogs lately... everyone either reviewing an existing system or designing thier own thoughts of what a storage system should be like. However alot of them are very fixed and have specific uses. Some are more dynamic while others are more static but easier to use. An object storage is more than storing or even finding information. It's about creating a single design which can encapsulate any information in the world and relate between them in any way needed. This could be anything from inheritence, backup, sharing, attachments etc. Here is part of my design: (will update as needed) Screens Environment is based on a powerful, flexible object model which allows representing any information in a connected and global interface. An object is an atomic unit of information which can represent anything from small name identifiers to huge structures. Each object is indexed for quick searching and has a handle to quickly relocate an object with minimal performance lag. This is done by using the unique identifier of the object in conjunction with the objects index. Objects alone are not useful; you need to specify relationships between them. Objects use links to specify relationships between other objects. Both the source and target of a link holds a copy of the link so that both objects understand the direction of the link. An object can have multiple links targeting it or outsourcing it. Each object holds a name and type identifier to identify the content or linking structure of the object. Each link has a name identifier to identify the type of the link. Together objects and links create flexible resourceful object storage. Each object holds a content stream of any size and unless messages override the read/write capabilities of the object, the stream is stored in the object storage itself. There are multiple types of links: 1. Container – A container link is the most common link since its very basic and does not do much but define a relationship between a parent object and a child object. 2. Reference – A reference link allows jumping between structures. 3. Class – A class link inherits any objects of the target which are linked via container links even multiple depths of links. Local or extended objects (non inherited objects) override inherited objects. 4. Extended – An extended link allows extending an object structure with another structure however unlike a class link an extended link overrides local objects. If multiple extended links clash, the last extended link prevails. Because many objects need interfaces to handle them, use method objects. Method objects are normal objects with the link name 'method' and are handled by the system. Because they are objects they can be extended or inherited via links. The name and type identifier of the object is the method identifiers. The method object holds a reference link (type 'code') to the object which handles the actual code. Method objects hold in their structure the parameters that can be sent with the method. If you try and send with non extended parameters they are 'cut' and not sent with the method. This stops 'secret' parameters from creeping into the system. Each parameter holds a name and type and can hold default values if the message did not include them. All parameters should be optional on sending and should be rejected if more information is needed. You don’t send a message to a method object but rather to the source of the method link. The message code finds the correct method handler (either through inheritance, extended or via containers) and finds the code of the method (via the 'code' link) and calls the code directly (native code). Non native code like java code is done by inheritance. You base the method on the compiler object (like the java object) and all methods are redirected to the compiler object. You can of course override this behavior by basing the object on a different code object which is useful when objects want to switch dynamically between dynamic codes. An object can exist without methods however its content is static (not dynamic by a method) and is stored in the object storage itself. To override this, just link to a method object with the read/write identifiers. When Screens Environment will try to read/write to the content of the object it checks if any method links exist (either via inheritance, extended or containers) and if not uses system code. While container and reference links provide a tree structure (parent/child) , the class and extended links provide a way to merge multiple objects together without having to know of the merge (however can be found out if needed). Think of container and reference links as down/up links while class and extended links as left/right links which together allow the full flexibility that the object storage needs. Applications normally create class objects so that methods are not required for each object instance but rather derive it from the class object. The reason a class is an object is because it increases the flexibility of the storage.