Yep, that's what what I was actually looking for - to have interface like
local search (text field and button on the map) but make it perform
geocoding instead.

On Wed, Jan 28, 2009 at 1:34 PM, Yaron Koren <[email protected]> wrote:

> Yeah, that LocalSearch is a very intuitive interface. The fact that you
> can't set the text, and thus change the language, might be a deal-breaker,
> though.
>
> What about just making the existing address-lookup input look more like
> LocalSearch's? I'm imaging something that looks like this:
>
> ----------------------
> | Search the map     |  Search
> ----------------------
>
> (Hopefully that fixed-width formatting showed up correctly.) The input
> itself contains a gray "Search the map" string, that disappears as soon as
> the user clicks in the input; then there's a "Search" button or link next to
> it that the user presses to do the actual lookup.
>
> Potential solution?
>
> -Yaron
>
>
>
> On Wed, Jan 28, 2009 at 1:17 PM, Sergey Chernyshev <
> [email protected]> wrote:
>
>> Yep, I agree - clearing the input seems odd if you clear the input, but if
>> it's kept, then it's not clear to the user why that address is not saved,
>> but coordinates instead - this can be solved by the in-pan control like
>> Local Search or similar where it's sort-of clear that this window is only
>> for looking stuff up.
>>
>> As for reverse geocoding, I think it well depends on the use case - for
>> things like specifying location for the event, it makes sense to know where
>> it is but not knowing the address or another example - when you need to post
>> location of the address of the Deli you go to every day - you know where it
>> is on the map, but has no idea about coordinates or address. The question is
>> if it should be used for entering map coordinates or for entering addresses
>> (another type of data).
>>
>>           Sergey
>>
>>
>>
>> On Wed, Jan 28, 2009 at 1:09 PM, Yaron Koren <[email protected]> wrote:
>>
>>> Thanks for this feedback. The first suggestion - do automatic lookups,
>>> clear the input as soon as a lookup succeeds - seems odd. If you type in a
>>> whole address, then realize there was a typo in the number, you'll have to
>>> type it all again, no?
>>>
>>> Ooh, that LocalSearch control is neat - really neat. I've never seen it
>>> before. It might be worth looking to see if it can be integrated with the
>>> rest of the form input.  One possible downside, though, is that the text it
>>> uses (like "search the map") is probably not internationalizable.
>>>
>>> It might make sense to increase the map size. This is already a settable
>>> parameter, by the way.
>>>
>>> Reverse geocoding, AKA finding a street address from a selected point,
>>> might be more trouble than it's worth - if the place the user is entering
>>> has a street address, it seems like the chance would be much higher that the
>>> user knows that address than that he/she knows its location on the map.
>>> Plus, if the user wants to enter just coordinates and not an address, say,
>>> for privacy reasons (if they're entering their own location), this might
>>> just confuse the issue. Yes, you could argue that entering coordinates is
>>> itself giving up your privacy, but I would guess that at least some people
>>> enter a point in the general area of where they are, just so they can show
>>> up on a map.
>>>
>>> -Yaron
>>>
>>>
>>> On Wed, Jan 28, 2009 at 12:44 PM, Sergey Chernyshev <
>>> [email protected]> wrote:
>>>
>>>> I was terribly disgusted with the interface when I started to use it on
>>>> TechPresentations.org - it definitely needs some improvement.
>>>>
>>>> My thoughts - as tosfos suggests, it's better to update non-editable
>>>> area based on either user clicking on the map or by using lookup. In
>>>> addition to that I would suggest that lookup should happen when field is
>>>> changed, without user even pressing a button - once lookup is successful, 
>>>> it
>>>> should clear up lookup field. The only question is how to separate direct
>>>> input from looked up input - we should either rely on Google's geocoder to
>>>> return what was entered or try to parse the string and see if it's
>>>> coordinate (first one is easier and might suffice, second one helps not to
>>>> rely on Google geocoder service to be constantly available). Another
>>>> addition might be have same configuration, but to add in-place editing for
>>>> the coordinates value if the lable is clicked.
>>>>
>>>> Another alternative is to use LocalSearch control on the map instead of
>>>> lookup field:
>>>> http://code.google.com/apis/maps/documentation/examples/control-localsearch.html-
>>>>  it's quite neat and might be what we need. If this functionality is not
>>>> what user wants, than similar control just for geocoding might need to be
>>>> developed.
>>>>
>>>> In addition to this, I think default size of the map should be increased
>>>> significantly because right now it's too easy to move the cursor beyond
>>>> visible area and it become unclear if coordinates changed or you need to
>>>> click some point on the map to change those coordinates. Maybe it's worth
>>>> showing coordinates of current cursor to give user feedback that he needs 
>>>> to
>>>> click the map to change the resulting coordinates.
>>>>
>>>> BTW, I wonder if it makes sense to use reverse geocoding, new feature of
>>>> Google's -
>>>> http://code.google.com/apis/maps/documentation/services.html#ReverseGeocodingor
>>>>  maybe it's worth creating separate extension similar to
>>>> http://www.mediawiki.org/wiki/Extension:Google_Geocoder
>>>>
>>>>           Sergey
>>>>
>>>>
>>>>
>>>> On Tue, Jan 27, 2009 at 10:39 AM, Yaron Koren <[email protected]>wrote:
>>>>
>>>>> Tosfos - that's an interesting suggestion.
>>>>>
>>>>> Barry - well, even if the map input becomes user-configurable, I'd
>>>>> still like the default to be as nice as possible. But I guess your sample
>>>>> code was also a recommendation for the default layout and text.
>>>>>
>>>>> -Yaron
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jan 27, 2009 at 9:44 AM, Barry <[email protected]> wrote:
>>>>>
>>>>>>
>>>>>> I'm in favor of giving the form designer as much control as possible.
>>>>>> Could the "field" be entered as three coordinated fields?
>>>>>>
>>>>>> In addition to:
>>>>>> | '''Geographic coordinate''' in the form "<nowiki>45.4564°N,
>>>>>> -23.456°E</nowiki>".
>>>>>> {{{field|coordinate|input type=googlemap}}}
>>>>>>
>>>>>> How about adding:
>>>>>> | '''Enter address of location.'''
>>>>>> {{{field|coordinate|input type=googlemap_address}}}
>>>>>> |-
>>>>>> | '''Or, enter geographic coordinate''' in the form
>>>>>> "<nowiki>45.4564°N, -23.456°E</nowiki>".
>>>>>> {{{field|coordinate|input type=googlemap_coordinate}}}
>>>>>> |-
>>>>>> | '''Or, find the location on the map'''.
>>>>>> {{{field|coordinate|input type=googlemap_map}}}
>>>>>>
>>>>>> You could link them together by the field name and still support
>>>>>> the existing version as with type="googlemap"
>>>>>>
>>>>>> You could even allow the form designer to include only one or two of
>>>>>> the fields,
>>>>>> so a cartographer could use the coordinate field and leave off the
>>>>>> address.
>>>>>>
>>>>>> (I know this is at least an order of magnitude more difficult than
>>>>>> rearranging the form elements,
>>>>>> but you asked...)
>>>>>>
>>>>>> - Barry
>>>>>>
>>>>>> On Jan 26, 12:49 pm, Yaron Koren <[email protected]> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I've gotten the sense recently that some or many users find the
>>>>>> Semantic
>>>>>> > Google Maps form input confusing, especially when they first try to
>>>>>> use it.
>>>>>> > To refresh your memory, here's an example of the form input in
>>>>>> action:
>>>>>> >
>>>>>> >
>>>>>> http://hackerspaces.org/w/index.php?title=Santa_Fe_Complex&action=for.
>>>>>> ..
>>>>>> >
>>>>>> > It consists of three parts: an input of geographical coordinates
>>>>>> (which is
>>>>>> > what actually gets saved to the template), a map input (which also
>>>>>> sets the
>>>>>> > coordinates), and an entry for placing an address, then looking up
>>>>>> that
>>>>>> > address (which sets the values of both the coordinate and map
>>>>>> inputs). With
>>>>>> > that many inputs, and the lack of any explanatory text, it's no
>>>>>> wonder that
>>>>>> > some people get confused.
>>>>>> >
>>>>>> > So: does anyone have any thoughts on ways the input could be
>>>>>> improved?
>>>>>> > Perhaps the two text entries should be reversed, with the address
>>>>>> lookup on
>>>>>> > top? Or maybe one of the text entries should be placed to the right
>>>>>> of the
>>>>>> > map, instead of the top or bottom? Maybe "look up coordinates"
>>>>>> should be
>>>>>> > changed to "look up address"? Or maybe that text should appear,
>>>>>> unlinked,
>>>>>> > before the entry, with something like "Go" appearing after the entry
>>>>>> as the
>>>>>> > actual link?
>>>>>> >
>>>>>> > Any thoughts are welcome. Also, if you know of any existing inputs
>>>>>> on the
>>>>>> > web that do something similar, that would be helpful to know about
>>>>>> too.
>>>>>> >
>>>>>> > Thanks,
>>>>>> > Yaron
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergey Chernyshev
>>>> http://www.sergeychernyshev.com/
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Sergey Chernyshev
>> http://www.sergeychernyshev.com/
>>
>>
>>
>
> >
>


-- 
Sergey Chernyshev
http://www.sergeychernyshev.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Semantic Forms" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/semantic-forms?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to