[Loadstone] Find & show area

arimo at iki.fi arimo at iki.fi
Sun Jan 13 10:04:50 GMT 2008


Hi Shawn

On Sat, 12 Jan 2008, Shawn Kirkpatrick wrote:

> There's no real duplicated functions in navigation and exploration mode.
> There are similar functions, like find point and show area but they
> act different depending on the mode. In exploration mode find point and show
> area start from your virtual position but in navigation mode they start from
> the current gps position. A small difference but an important one.

  I talked about current exploration mode where both arrow keys and number 
dublicate the lookaround function. Of course navigation and exploration 
use different information  where to start and what is considered 'up' 
direction but for user experience these should be as similar as possible.

> In exploration mode using the arrows for anything doesn't really work
> because the 4 way arrows are a bad fit for the 8 numeric keys. I have plans
> at some point for the arrows anyway so there current functions will change
> in exploration mode at some point.

   Let's see.  I'm used to work with proximity-sorted list with other 
applications and found them faster  to use even the calculation of the 
list would require some extra seconds. The more i have collected PPOIS and 
intersections the  slower current lookaround method becomes to use. This 
is not due the calculation delays but just with hit and miss nature of 
this method.

> As far as the numeric keys in exploration mode go, short press moves and
> long press looks. It's going to stay that way, the reverse way was tried and
> the entire developement team hated it to the point where they refused to use
> the versions with this in. At some point the keys in exploration mode may be

  Interesting. Were the results similar in unknownareas too? Was this 
arrangement used in some publically availalble version?

> mapable so the user could set this up how they'd like.

  This would solve the problem forever.

> I don't think any of the keys in exploration mode should be relative to
> current heading, the idea is to have a stable base to work with while
> exploring an area. To have relational data is what navigation mode is for.

  It depends if we are thingking about programmer's point of view or user's 
point of view. When walking relative headings are easier to use for most 
users, similar to sighted who do not thing some item is for example at 
north, it is in the left or rigth depending their currend heading or where 
they are facing to. It will help those user's if they can use the same 
relative direction base in exploration mode too.  Afaik  mobility 
instructors or dog handlers also use relative headings, too.

  We have planned a meeting int the beginning of february to discuss about 
gps-related issues with mobility instructors and guide dog traimers. After 
this i think i know even more what features would be considered most 
useful for also non-technically oriented users.

  btw: i had an interesting experience of the reverse effect yesterday: i 
have an old Globalsat that reports always heading to north with low 
walking speeds. I found it  very hard to orientate even in familiar 
environment when i had to use only compass directions.

> In a result list hitting select will move the exploration mode focus to the
> current result. If this is done in navigation mode then exploration mode is
> entered.

  Yes, this is the  intented purpose. Otherwise it is very hard to find 
that point in the exploration mode. This is the sortcut to edit, move or 
track point found while navigating.

  To minimize confusion for users window title could be altered according 
current mode.


> Of course a lot of these changes are coming in the next release, the current
> release was the first try with the new find point and show area system.

  Ok. I really like these functions and hope they get even easier to use.

> Getting the find point and show area to work with checkpoints only may or
> may not happen. There's a lot of technical problems getting the checkpoint
> information to these functions. It would turn a currently rather clean and
> optimized bit of code in to a nightmareish confusing mess.

  Ok. Not an issue. How about plain key = show area (in given direction], 
shifted = find point (in given direction)?

>  The size of the database will effect the speed of all queries. This
> is
> because the database engine on the phone really sucks. We need a free, open
> source database that'll run on series60 v1, v2, and v3. If anyone can find
> this I'd be very happy.
> The search radius kind of works like you describe. It starts off
> small creating a latitude/longitude box to search within and then expanding
> until it hits the maximum radius specified.

  Ok, this explains the impact of number of results.  Would it be possible 
to turn the concept around: use a smaller radius and find all points in 
this radius. Continue search will then expand this radus and re-search. 
User can set default radius according their surroundings and find point 
-function has a dialog to set it  for every search.


  >
> On Sat, 12 Jan 2008, Ari Moisio wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> 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