Special Zaurus Considerations When developing for the Zaurus there are special considerations that must be taken into account.  From reduced binary size to using the documents folder. 1) The PDA Factor     When users see a pda they see two things on it.  First is their applications, second is their documents.  They do not care what version of Linux the pda runs or what computer language the applications were written in.  Users should be able to do everything they need to without having to browse the file system or use the command line.  Remember that the file manager doesn't come by default on the 5500 and its presents can't be guaranteed. From within the application users shouldn't be able to browser the file system.  It should be assumed that a document will only be in one of three places: CF card, SD card, and the Documents tab*.  Unless the application is geared completely toward developers/power users there should be no reason for the application to need to create a custom file dialog that can view the entire system.  An application that views/edits documents should uses qpe's built in classes for document handling.   For applications that want the users to select a folder they should allow basic browsing capabilities. Perhaps presenting the user with a list of the three base locations and then only showing directories with folders that can be displayed.  Allowing them to browse around in "/" would be considered a bug though. *Network would be a forth location, but we are speaking locally and if the application can browse over the network then it is in a different category, but the same rules should still apply on not being able to browse everywhere locally. 2) Size (Both binary and screen size)     When developing for the Zaurus the size of the application should be taken into account, both binary and screen real-estate.     A lot of users who are using applications on their Zaurus will not be looking for every bell and whistle that an application can offer.  They are looking to do basic jobs, see the one page help doc and not much else.  (That is unless that is the point of the product as many vertical apps are)  Many things can be removed to reduce the binary size. of an application: templates, sample data, printing capabilities, imports, exports, extra options, themes, old options and historical code/baggage that isn't needed.  Every applications is different and each one should be separately looked at to see what is not needed and can be removed.  Cleaning house is always a good thing and it might be found that in reducing the complexity and size of an application can also increase its speed.     With the Zaurus screen applications will not have the luxury of a 1024x768 desktop anymore.  Many dialogs will need to be reworked to fit the screen.  Take note of Message dialogs that pop up to make sure that they fit into the screen.  Removing features is one excelent way of helping to fit an application on the smaller screen and reduce the binary size.  Options dialogs are one of the hardest items to rework sense they typically will be much larger then the Zaurus's size.  Also try to have the application fill the entire screen.  Being 3 pixels smaller then then top looks bad. 3) Just because it is Linux...     Many applications that are being developed for the Zaurus are by Linux developers.  Unfortunately this is starting to lead to the montra that it is ok to have the application half broke, with console use mandatory. (Note I didn't say half finished, but half broke)  This should not be the case.  PDA users expect there apps to work more then any other group even more then mac users.  When an application for OSX is released they come with full featured polished ui frontends.  Even Apache did.  When developing for the Zaurus try to do the same.  When an ipk is released it should work on install.  It should have a gui that works.  And if it doesn't have a gui it should be turned on when installed and turned off when uninstalled.  Users should never ever have to use the command line.  This is a power tool for developers to use and a "cool" factor to show a buddy how vi is on the pda. It shouldn't be an application requirement. 4) User Interface goodness     When designing the application please try to apply the general ui design rules.  If you have never had any formal ui schooling I recommend picking up a book such as GUI Bloopers , sitting down for a few hours and reading through it.  If you already have ui knowledge spend ten minutes and criticize your own application or even have someone else do it.  You might be surprised what got into the application. 5) The final rule* If you are thinking about adding some special feature such as: -My whole app will be PINK! -I like KDE3's 22MB theme so I require it. -Custom home brew tabs that are upside down! -I made my own file dialog that looks like no one elses... -Full screen always! -Changes the Ok button to flip the screen 1/3 times it is pressed (randomly of course) and doesn't do anything the user wants. -etc First off sit back and think about this for a second.  More then likely this will be a lot of effort on your part, be unlike any other application and add *no* real value.  In fact in the grand scheme it will probably hurt the application because it will feel different then any other application.  In Qt if an application has to overload a class to give it some special feature think first if there is a correct thing to do that feature that doesn't require a lot of work.  If a lot of extra effort has to be made to make every screen have rainbow colors maybe there is a reason it is so hard.  The general rule is if you want to do something special, don't. *Games are about the only thing that can break this and get away with it, but even then think first.

    This page was last updated: Wednesday, 09-Apr-2003 04:57:24 PDT