[Loadstone] Find & show area

Ari Moisio arimo at netsonic.fi
Sat Jan 12 17:56:03 GMT 2008


Hi Shawn


On Thu, 10 Jan 2008, Shawn Kirkpatrick wrote:

> There's a bit of inconsistancy with the keys in navigation and exploration
> mode, mainly with the long star and shift star. This because in navigation
> mode the shift star was already used and in exploration mode long star has
> been allocated to the new show point comment function that was deemed to be
> more often used than the find point function. Since the keys in navigation
> mode can be remapped the user can fix the inconsistancies if it's a real
> problem.

  After remapping keys we have duplicate keys sets in both exploration and 
navigation modes.

  Here a one proposal more: applicable for bot exploration and navigation 
modes:

- Short arrows and shifted arrows as usual although it would be nice to 
arrows in the exploration mode also use up arrow as heading of last 
movement, virtual or real. There are already keys for compass direction 
lookarounds. If we have to use shifted and long keyp resses because lack 
of key first thing would be to remove duplicate plain key commands. Also 
to have consistency as much as possible. For example using shift key to 
bypass check status is a good idea but it should be then implied 
everywhere. Another consistency item is to have short key presses for 
looking around and long for virtually moving. Also having keys function 
similar for most situations, ie not look forward in one mode ad look north 
in another would help beginner get familiar with the application.


- Long arrow keys open show area -like list in given direction, +- 55 
degrees or so to avoid  dead cones. if there are chekced points only those 
are shown.

- Shift + long arrows similar to long arrows but showing all points 
regardles of their chek status.

- Long select will open find point -type dialog. If search string is left 
empty it will list all found points in given area. ONe extra selection is 
a check box to select if only checked points are included. For consistency 
reasons this box could be checked with plain long select if there are any 
checked points and not checked with shifted long select.

- When pressing select in result list LS will enter exploration mode with 
focus on selected point.

About execution times:  if search string es empty there is no need to 
perform any string comparisons either.

  If number of result have severe impact on search times there are 
something very severely broken in the search engine.

  If we have a search radius one way to minimize computation is to 
calculate limits for lat and lon coordinates and calculate exact distance 
only those items within those ranges. In this setting it also makes sense 
to have lower search radius. Continue search might then expand this radius 
and search for new points.

> The show area and find point functions are almost the same as far as code
> goes but the show area doesn't do a string search. The reason for this is
> clear, show area is for looking at what's around you without knowing any
> part of the name, and find point is to find a point when you know the name
> or partial name of the point you're looking for. A find point will be slower
> than a show area because of the additional work involved with the text
> comparison.
> If you have a small database then getting results will be quite fast. Scale
> this up thoe, say 100000 points or so, and things start to slow down quite a
> bit. At those levels even 10 results for a show area will take a few
> seconds. The higher the number of returned results the longer the response
> time will be.
> When doing a find point you don't really need fine resolution since the
> exact location of the point isn't known or you wouldn't need to find it in
> the first place. Having the search radius in kilometres doesn't prevent the
> function from finding a point less than a kilometer away and has no effect
> on the way the distance is reported.
> As far as units go it probably makes the most sence to have them in the most
> common representation that people will use for the given purpose. This means
> that larger values would be in kilometres and smaller ones in metres.
>
> On Thu, 10 Jan 2008, Ari Moisio wrote:
>
>> Hi Shawn
>>
>>
>> On Wed, 9 Jan 2008, Shawn Kirkpatrick wrote:
>>
>>> The new system does something like that. In navigation mode the long arrows
>>> will do a show area in that direction and long select does a show area in
>>> all directions. Find point can be mapped to a key and defaults to long * but
>>> that may change before release. In exploration mode shift of the numeric
>>> keys will do a show area in the given direction and shift 5 will do it for
>>> all directions. There's a shortcut to find point with shift *.
>>
>>  Ok,  sounds good. There is however still inconsistency between navigation
>> and exploration modes.
>>
>>> There's probably no point in bringing up the dialog on a show area since
>>> it's likely to find something unless you have a database with not much in it
>>> and an unreasonable search radius.
>>
>>  I still wonder is the only difference betweeen find point and show are
>> the lack of dialog in the show area -function. For end-user's point of
>> view two almost similar functions is no good at all.
>>
>>> You couldn't represent the search results in screenfulls (on what size
>>> screen?) since there's only one result on screen at any one time. More often
>>> than not you want a low number of search results to start with anyway.
>>
>>  There were those quotation marks  for a reason. Why shall i want a low
>> number of results  at first time. Even 6680 can calculate 25 results - my
>> current default - faster than screen reader could read the first line.
>>
>>> Having the search radius in kilometres makes sence since you're probably
>>> searching for points further away from the current position. Having the
>>> number in metres would just result in bigger numbers.
>>
>>  Bigger numbers but also finer resolution. For orientation purposes some
>> point at south 2.7 kilometers apart is quite useless.
>>
>>> Unfortunately the user interface just doesn't seem to provide any good to
>>> specify what units things should be in. By the time you get the prompt up
>>> there's no room for anything else. Even worse symbian does provide for doing
>>> things like this but series60 doesn't use those fields for some reason.
>>
>>  For this reason units should be as consistent as possible.
>>
>>>
>>> On Wed, 9 Jan 2008, arimo at iki.fi wrote:
>>>
>>>> Hi
>>>>
>>>> On Tue, 8 Jan 2008, Shawn Kirkpatrick wrote:
>>>>
>>>>> This could probably be done but that would introduce an extra step in the
>>>>> show area function making it a bit slower to access.
>>>>
>>>>  The access speed difference is plusminuz zero, one extra selecto for one
>>>> less arrow down. There is currently six keystrokes to get from navigation
>>>> mode to show area.
>>>>
>>>>> Access to these functions has been improved for the next version.
>>>>
>>>>  Great:-) How about following scheme in both navigation and exploration:
>>>> arrow will open show area -type list in given direction and pressing
>>>> select will open current find- type dialog in all directions.
>>>>
>>>>  To stay even more consistent between exploration and navigation modes
>>>> arrow up could always be  'in front', ie  in exploration mode heading of
>>>> latest virtual movement.
>>>>
>>>>
>>>>> I've been thinking of making the find dialog save the last search criteria
>>>>> but don't know if it'll get put in or not.
>>>>
>>>>  I'll vote to put it on.
>>>>
>>>>> For the results field you can type in the number instead of using the
>>>>> arrows. I think the adjustment step is handled by the dialog framework and
>>>>> might not be adjustable.
>>>>
>>>>  Ok... how about  defining it as a 'screenfulls', ie for example ten
>>>> results per single unit?
>>>>
>>>>> The search radius is in kilometres, consistant with other things.
>>>>
>>>>  I haven't found any other setting presented in kilometers so far.  They
>>>> are in metres, seconds or just numbers.
>>>>
>>>>
>>>>
>>>> You can still escape from the Gates of hell: Use Linux!
>>>> --
>>>> mr. M01510
>>>>
>>>>
>>>> _______________________________________________
>>>> Loadstone mailing list
>>>> Loadstone at loadstone-gps.com
>>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>>>
>>> _______________________________________________
>>> Loadstone mailing list
>>> Loadstone at loadstone-gps.com
>>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>>
>> You can still escape from the Gates of hell: Use Linux!
>> --
>> mr. M01510
>>
>>
>> _______________________________________________
>> Loadstone mailing list
>> Loadstone at loadstone-gps.com
>> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>>
> _______________________________________________
> Loadstone mailing list
> Loadstone at loadstone-gps.com
> http://www.loadstone-gps.com/mailman/listinfo/loadstone
>
You can still escape from the Gates of hell: Use Linux!
-- 
mr. M01510




More information about the Loadstone mailing list