Special Considerations - Revision history

Tux: Development category

2007-11-25T20:47:01Z

Development category

←Older revision		Revision as of 20:47, 25 November 2007
Line 35:		Line 35:

	<sup id="note3">3[[#ref3\|'''^''']]</sup> Games are about the only thing that can break this and get away with it, but even then think first.		<sup id="note3">3[[#ref3\|'''^''']]</sup> Games are about the only thing that can break this and get away with it, but even then think first.
		+	[[Category:Development]]

Meyer at 03:46, 26 September 2007

2007-09-26T03:46:10Z

←Older revision		Revision as of 03:46, 26 September 2007
Line 2:		Line 2:

	==The PDA Factor==		==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 presence can't be guaranteed. From within the application users shouldn't be able to browse 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<sup>1</sup>. 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.	+	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 presence can't be guaranteed. From within the application users shouldn't be able to browse 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<sup id="ref1">[[#note1\|1]]</sup>. 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.

	==Size (Both Binary and Screen Size)==		==Size (Both Binary and Screen Size)==
Line 15:		Line 15:

	==User Interface Goodness==		==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.	+	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''<sup id="ref2">[[#note2\|2]]</sup>, 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.

-	==The Final Rule<sup>2</sup>==	+	==The Final Rule<sup id="ref3">[[#note3\|3]]</sup>==
	If you are thinking about adding some special feature such as:		If you are thinking about adding some special feature such as:
	*My whole app will be PINK!		*My whole app will be PINK!
Line 30:		Line 30:

	==Notes==		==Notes==
-	<sup>1</sup>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.	+	<sup id="note1">1[[#ref1\|'''^''']]</sup> 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.

-	<sup>2</sup>Games are about the only thing that can break this and get away with it, but even then think first.	+	<sup id="note2">2[[#ref2\|'''^''']]</sup> Johnson, Jeff (2000). ''GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers''. Morgan Kaufmann. ISBN 1558605827.
		+
		+	<sup id="note3">3[[#ref3\|'''^''']]</sup> Games are about the only thing that can break this and get away with it, but even then think first.

Meyer at 03:07, 26 September 2007

2007-09-26T03:07:03Z

←Older revision		Revision as of 03:07, 26 September 2007
Line 1:		Line 1:
-	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.		When developing for the Zaurus there are special considerations that must be taken into account. From reduced binary size to using the documents folder.

	==The PDA Factor==		==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*.	+	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 presence can't be guaranteed. From within the application users shouldn't be able to browse 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<sup>1</sup>. 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.
-	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.	+	==Size (Both Binary and Screen Size)==
-		+
-	==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.		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.	+	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 application 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, you have to work with 240x320. 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.	+	With the Zaurus screen applications will not have the luxury of a 1024x768 desktop anymore, you have to work with 240x320. 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 sinse 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.

-	==Just ~~because~~ it is Linux...==	+	==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.	+	Many applications that are being developed for the Zaurus are by Linux developers. Unfortunately this is starting to lead to the mantra 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 applications to work more then any other group even more then Mac users. When an application for OS X 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.

-	==User Interface ~~goodness~~==	+	==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.	+	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.

-	==The final rule*==	+	==The Final Rule<sup>2</sup>==
	If you are thinking about adding some special feature such as:		If you are thinking about adding some special feature such as:
-	-My whole app will be PINK!	+	*My whole app will be PINK!
-	-I like KDE3's 22MB theme so I require it.	+	*I like KDE3's 22MB theme so I require it.
-	-Custom home brew tabs that are upside down!	+	*Custom home brew tabs that are upside down!
-	-I made my own file dialog that looks like no one elses...	+	*I made my own file dialog that looks like no one elses...
-	-Full screen always!	+	*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.	+	*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	+	*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.

-	~~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.	+	==Notes==
		+	<sup>1</sup>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.

-	~~(*)~~ Games are about the only thing that can break this and get away with it, but even then think first.	+	<sup>2</sup>Games are about the only thing that can break this and get away with it, but even then think first.

Offroadgeek at 02:18, 28 November 2004

2004-11-28T02:18:11Z

←Older revision		Revision as of 02:18, 28 November 2004
Line 4:		Line 4:

	==The PDA Factor==		==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.	+	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.		(*) 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.

	==Size (Both binary and screen size)==		==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.	+	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, you have to work with 240x320. 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.	+	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, you have to work with 240x320. 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.

	==Just because it is Linux...==		==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.	+	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.

	==User Interface goodness==		==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.	+	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.

	==The final rule*==		==The final rule*==
Line 32:		Line 35:

	(*) Games are about the only thing that can break this and get away with it, but even then think first.		(*) 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: May 21 2003 06:33:31.

Offroadgeek at 02:16, 28 November 2004

2004-11-28T02:16:48Z

New page

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.

==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.

==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, you have to work with 240x320. 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.

==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.

==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.

==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: May 21 2003 06:33:31.