Map Application - GSoC 19

classic Classic list List threaded Threaded
133 messages Options
1234567
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Ecaterina Moraru (Valica)
Hi,

How about:
* Maximizing the app area by removing the right panels;
* Have the map take all the available space
https://up1.xwikisas.com/#CnVVQ4JOC1ZPzAHSSbyAaQ
  * Controls: Search, Full Screen, Zoom

* If the user want to search
https://up1.xwikisas.com/#UYDXywBeRfcwLX6d06NVtA
  * expand the search control: allow input and facets using an overlay

* If the user has results https://up1.xwikisas.com/#LoeVbE9idboPvoG2w3dE0Q
  * display using overlay. center map on result click
  * allow further filtering through facets

These are just ideas, maybe there are other solutions.
Thanks,
Caty


On Wed, Jun 19, 2019 at 6:59 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad, hi all,
>
> > Hi all,
> >
> >     I just gave a try to the latest code, well done with the Solr
> queries and the search integration in the user interface, that's cool!
> >
> > Thanks Stephane. :)
> >
> >     Imho the most convenient UX is the following for these widgets,
> something similar to this map:
> >
> >     http://carte.preference-commerce.fr/cci-fr/
> >
> >     That is:
> >
> >     - The facets can get activated from a button. When they get
> activated, they show up in an overlay panel on top of the map, without
> hiding the list.
> >     - The list gets displayed under the search input, in an overlay as
> well, and can be completely hidden on request
> >
> >
> > Just to clarify things, the facets here refer to the "Refine your
> search" area, the search input refers to the "Search in map" text input and
> the list refers to the map item search results. Is that right?
>
> Yes indeed,
>
> > If so, I believe, given the nature of XWiki's design with widgets to
> both the right and left (for the default flavor), the space is a little
> cramped for overlaying anything on the map. For the implementation of full
> screen maps, we can overlay search and facets but for the normal view, the
> map will become very small.
> >
> > Here is a mockup I prepared based on my understanding of your
> suggestions: https://up1.xwikisas.com/#SB7B5mLNnfnUVAogWTLarw
> > Let me know what you think?
>
> I think it's an efficient way to layout the widgets indeed. I agree the
> map may look cramped in case there are panels on the left and on the right,
> but the user typically would have an option to hide the results, ideally.
> There's one change I would suggest, that would be to layout the filters
> either as an overlay or as a replacement of the list, and to move the
> filter button closer to the search input. Regarding the filter position:
> the Airbnb search illustrated below behaves quite nicely imho (when you hit
> "More filters", you get a new panel on top with all the filters), what do
> you think?
>
>    https://up1.xwikisas.com/#zNABtIwH-Z-hSSUgFx-y4Q
>
> As for the information associated with each point or area, we have several
> options: either place it in popups on top of the map like Airbnb, or have
> it in the search result area, like what Google Maps proposes, or display it
> in a lateral panel like GoGoCarto. I would opt for popups by default, and
> if possible later on, leave the option to display it in the search area in
> case of large content, what do you think? Ideally, the panel for displaying
> this information would be a template that could be easily styled and
> customized for each map?
>
> > I have also come up with an idea to generalize the museum maps import
> and export you created, Stephane. We could have a standard form of wikidata
> query with some extra custom parameters for each location like the
> MuseumClass in the Museums' case. These extra parameter will be checked in
> JSON and classes will be created if required so that objects can be
> associated to each map item and then later facets can be used based upon
> these newly created classes.
> > WDYT?
>
> I think that'd be a nice feature generally speaking to ease the import of
> Wikidata into XWiki indeed, I have a side project on which I'm considering
> such developments as well, not sure yet about the outcome. If you feel like
> it will be useful for generating more demo maps, I'd say that'd be good
> indeed, but with the caveat of not digging too much in that direction for
> not hampering the map development of course.
>
> > Also, due to unprecedented circumstances within college, my exams have
> been delayed for this week and will start from next week. So I will be
> working this whole week on the project as opposed to what I told earlier.
>
> Ok, thank you for letting us know.
>
> I'd say at this stage that'd be great to keep progressing on functional
> testing automation and to finalize and release 1.0, I guess we're in tune
> but, as you did since the beginning, don't hesitate to raise questions
> about the priorities and the next steps of course.
>
> Wishing you good work days ahead,
>
> Cheers
>
> Stéphane
>
>
> > Best,
> > Fawad
> >
> >
> > On Mon, Jun 17, 2019 at 11:04 PM Stéphane Laurière <[hidden email]
> <mailto:[hidden email]>> wrote:
> >
> >     Hi Fawad, Caty, all,
> >
> >      > Hi all,
> >      > Hoping that everything is going well.
> >      >
> >      > Stephane, I was able to do implement most of your suggestions
> except the search results list.
> >
> >     I just gave a try to the latest code, well done with the Solr
> queries and the search integration in the user interface, that's cool!
> >
> >      > I am not too sure where I should place it. As per the latest
> build, the filter widget appears to the left. Do you think it is practical
> that we replace this widget with the search results when the user wants to
> see the search results and show the widget back again when the user clicks
> on the widget control? I am not too sure what approach I should choose here
> in terms of UX.
> >      > Ecaterina, your views on this would help a lot. Thanks. :)
> >
> >     Imho the most convenient UX is the following for these widgets,
> something similar to this map:
> >
> >     http://carte.preference-commerce.fr/cci-fr/
> >
> >     That is:
> >
> >     - The facets can get activated from a button. When they get
> activated, they show up in an overlay panel on top of the map, without
> hiding the list.
> >     - The list gets displayed under the search input, in an overlay as
> well, and can be completely hidden on request
> >
> >     It's rather close to what Google Maps proposes as well, except that
> the facets replace the list in that case (when hitting "Autres filtres"),
> which is a bit less convenient in my opinion, but not a big deal:
> >
> >
> https://www.google.com/maps/search/Restaurants/@48.865957,2.352974,16z
> >
> >     What do you think?
> >
> >      > Also, do you foresee the map to take full browser height and
> width as is seen in all the examples you gave me?
> >
> >     That would be a nice feature to have a button on the map to turn it
> full-screen indeed, similarly to what happens with the XWiki text editor.
> >
> >     Cheers
> >
> >     Stéphane
> >
> >      > Regarding the release, I will try preparing everything by tonight
> so that it is available for your review, including the demo tests that
> Vincent suggested.
> >      >
> >      > Best,
> >      > Fawad
> >      >
> >      >
> >      > On Thu, Jun 13, 2019 at 12:59 PM Stéphane Laurière <
> [hidden email] <mailto:[hidden email]> <mailto:
> [hidden email] <mailto:[hidden email]>>> wrote:
> >
>
>
> --
> Stéphane Laurière
> XWiki – https://xwiki.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Ecaterina Moraru (Valica)
Regarding tests, there are some contrib apps with tests:
https://github.com/xwiki-contrib/application-forum/tree/master/application-forum-test
https://github.com/xwiki-contrib/application-tour/tree/master/application-tour-test

Good luck with your exams,
Caty

On Wed, Jun 19, 2019 at 7:32 PM Ecaterina Moraru (Valica) <[hidden email]>
wrote:

> Hi,
>
> How about:
> * Maximizing the app area by removing the right panels;
> * Have the map take all the available space
> https://up1.xwikisas.com/#CnVVQ4JOC1ZPzAHSSbyAaQ
>   * Controls: Search, Full Screen, Zoom
>
> * If the user want to search
> https://up1.xwikisas.com/#UYDXywBeRfcwLX6d06NVtA
>   * expand the search control: allow input and facets using an overlay
>
> * If the user has results https://up1.xwikisas.com/#LoeVbE9idboPvoG2w3dE0Q
>   * display using overlay. center map on result click
>   * allow further filtering through facets
>
> These are just ideas, maybe there are other solutions.
> Thanks,
> Caty
>
>
> On Wed, Jun 19, 2019 at 6:59 PM Stéphane Laurière <[hidden email]>
> wrote:
>
>> Hi Fawad, hi all,
>>
>> > Hi all,
>> >
>> >     I just gave a try to the latest code, well done with the Solr
>> queries and the search integration in the user interface, that's cool!
>> >
>> > Thanks Stephane. :)
>> >
>> >     Imho the most convenient UX is the following for these widgets,
>> something similar to this map:
>> >
>> >     http://carte.preference-commerce.fr/cci-fr/
>> >
>> >     That is:
>> >
>> >     - The facets can get activated from a button. When they get
>> activated, they show up in an overlay panel on top of the map, without
>> hiding the list.
>> >     - The list gets displayed under the search input, in an overlay as
>> well, and can be completely hidden on request
>> >
>> >
>> > Just to clarify things, the facets here refer to the "Refine your
>> search" area, the search input refers to the "Search in map" text input and
>> the list refers to the map item search results. Is that right?
>>
>> Yes indeed,
>>
>> > If so, I believe, given the nature of XWiki's design with widgets to
>> both the right and left (for the default flavor), the space is a little
>> cramped for overlaying anything on the map. For the implementation of full
>> screen maps, we can overlay search and facets but for the normal view, the
>> map will become very small.
>> >
>> > Here is a mockup I prepared based on my understanding of your
>> suggestions: https://up1.xwikisas.com/#SB7B5mLNnfnUVAogWTLarw
>> > Let me know what you think?
>>
>> I think it's an efficient way to layout the widgets indeed. I agree the
>> map may look cramped in case there are panels on the left and on the right,
>> but the user typically would have an option to hide the results, ideally.
>> There's one change I would suggest, that would be to layout the filters
>> either as an overlay or as a replacement of the list, and to move the
>> filter button closer to the search input. Regarding the filter position:
>> the Airbnb search illustrated below behaves quite nicely imho (when you hit
>> "More filters", you get a new panel on top with all the filters), what do
>> you think?
>>
>>    https://up1.xwikisas.com/#zNABtIwH-Z-hSSUgFx-y4Q
>>
>> As for the information associated with each point or area, we have
>> several options: either place it in popups on top of the map like Airbnb,
>> or have it in the search result area, like what Google Maps proposes, or
>> display it in a lateral panel like GoGoCarto. I would opt for popups by
>> default, and if possible later on, leave the option to display it in the
>> search area in case of large content, what do you think? Ideally, the panel
>> for displaying this information would be a template that could be easily
>> styled and customized for each map?
>>
>> > I have also come up with an idea to generalize the museum maps import
>> and export you created, Stephane. We could have a standard form of wikidata
>> query with some extra custom parameters for each location like the
>> MuseumClass in the Museums' case. These extra parameter will be checked in
>> JSON and classes will be created if required so that objects can be
>> associated to each map item and then later facets can be used based upon
>> these newly created classes.
>> > WDYT?
>>
>> I think that'd be a nice feature generally speaking to ease the import of
>> Wikidata into XWiki indeed, I have a side project on which I'm considering
>> such developments as well, not sure yet about the outcome. If you feel like
>> it will be useful for generating more demo maps, I'd say that'd be good
>> indeed, but with the caveat of not digging too much in that direction for
>> not hampering the map development of course.
>>
>> > Also, due to unprecedented circumstances within college, my exams have
>> been delayed for this week and will start from next week. So I will be
>> working this whole week on the project as opposed to what I told earlier.
>>
>> Ok, thank you for letting us know.
>>
>> I'd say at this stage that'd be great to keep progressing on functional
>> testing automation and to finalize and release 1.0, I guess we're in tune
>> but, as you did since the beginning, don't hesitate to raise questions
>> about the priorities and the next steps of course.
>>
>> Wishing you good work days ahead,
>>
>> Cheers
>>
>> Stéphane
>>
>>
>> > Best,
>> > Fawad
>> >
>> >
>> > On Mon, Jun 17, 2019 at 11:04 PM Stéphane Laurière <[hidden email]
>> <mailto:[hidden email]>> wrote:
>> >
>> >     Hi Fawad, Caty, all,
>> >
>> >      > Hi all,
>> >      > Hoping that everything is going well.
>> >      >
>> >      > Stephane, I was able to do implement most of your suggestions
>> except the search results list.
>> >
>> >     I just gave a try to the latest code, well done with the Solr
>> queries and the search integration in the user interface, that's cool!
>> >
>> >      > I am not too sure where I should place it. As per the latest
>> build, the filter widget appears to the left. Do you think it is practical
>> that we replace this widget with the search results when the user wants to
>> see the search results and show the widget back again when the user clicks
>> on the widget control? I am not too sure what approach I should choose here
>> in terms of UX.
>> >      > Ecaterina, your views on this would help a lot. Thanks. :)
>> >
>> >     Imho the most convenient UX is the following for these widgets,
>> something similar to this map:
>> >
>> >     http://carte.preference-commerce.fr/cci-fr/
>> >
>> >     That is:
>> >
>> >     - The facets can get activated from a button. When they get
>> activated, they show up in an overlay panel on top of the map, without
>> hiding the list.
>> >     - The list gets displayed under the search input, in an overlay as
>> well, and can be completely hidden on request
>> >
>> >     It's rather close to what Google Maps proposes as well, except that
>> the facets replace the list in that case (when hitting "Autres filtres"),
>> which is a bit less convenient in my opinion, but not a big deal:
>> >
>> >
>> https://www.google.com/maps/search/Restaurants/@48.865957,2.352974,16z
>> >
>> >     What do you think?
>> >
>> >      > Also, do you foresee the map to take full browser height and
>> width as is seen in all the examples you gave me?
>> >
>> >     That would be a nice feature to have a button on the map to turn it
>> full-screen indeed, similarly to what happens with the XWiki text editor.
>> >
>> >     Cheers
>> >
>> >     Stéphane
>> >
>> >      > Regarding the release, I will try preparing everything by
>> tonight so that it is available for your review, including the demo tests
>> that Vincent suggested.
>> >      >
>> >      > Best,
>> >      > Fawad
>> >      >
>> >      >
>> >      > On Thu, Jun 13, 2019 at 12:59 PM Stéphane Laurière <
>> [hidden email] <mailto:[hidden email]> <mailto:
>> [hidden email] <mailto:[hidden email]>>> wrote:
>> >
>>
>>
>> --
>> Stéphane Laurière
>> XWiki – https://xwiki.com
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi Caty, Stephane and all,
Hope you are all well.

Stephane, your suggestions regarding the filter and search are great but I
feel the flow of our application is more inclined towards what Ecaterina
proposes. I will try implementing the mockups.

One problem we have though is that both our facets and search lead to a
reload of all the content inside the page asynchronously which means any
changes made through frontend are lost (like active dropdowns etc.). We
need to fix this.
Do you think I will have to redo both as a separate JSON service? I can
think of a way for search but facets are a little confusing.
Also, we still haven't found a way to fix the $facetDisplayer problem.
(
https://github.com/xwiki-contrib/application-interactive-maps/blob/master/application-interactive-maps-ui/src/main/resources/Maps/Code/CommonMacros.xml#L221
)
How do you think we should proceed with this?

Regarding the tests, I will start preparing them as soon as I am done with
implementing the new search and facets UI.
However, I do have confusion as to what kind of functional tests I should
perform. I am listing some that I have in mind.
- Map is created properly
- Facets are working
- Search returns expected results
- Popup works fine
And other similar functions.
I will need some guidance as to how I should take a start since I have not
actually made tests for real applications.
After analyzing some of the tests that Vincent and Ecaterina have shared, I
think we have to perform user actions programmatically and check to see if
the output we are receiving is correct. Is that right?

Thanks,
Fawad



On Wed, Jun 19, 2019 at 9:36 PM Ecaterina Moraru (Valica) <[hidden email]>
wrote:

> Regarding tests, there are some contrib apps with tests:
>
> https://github.com/xwiki-contrib/application-forum/tree/master/application-forum-test
>
> https://github.com/xwiki-contrib/application-tour/tree/master/application-tour-test
>
> Good luck with your exams,
> Caty
>
> On Wed, Jun 19, 2019 at 7:32 PM Ecaterina Moraru (Valica) <
> [hidden email]> wrote:
>
>> Hi,
>>
>> How about:
>> * Maximizing the app area by removing the right panels;
>> * Have the map take all the available space
>> https://up1.xwikisas.com/#CnVVQ4JOC1ZPzAHSSbyAaQ
>>   * Controls: Search, Full Screen, Zoom
>>
>> * If the user want to search
>> https://up1.xwikisas.com/#UYDXywBeRfcwLX6d06NVtA
>>   * expand the search control: allow input and facets using an overlay
>>
>> * If the user has results
>> https://up1.xwikisas.com/#LoeVbE9idboPvoG2w3dE0Q
>>   * display using overlay. center map on result click
>>   * allow further filtering through facets
>>
>> These are just ideas, maybe there are other solutions.
>> Thanks,
>> Caty
>>
>>
>> On Wed, Jun 19, 2019 at 6:59 PM Stéphane Laurière <[hidden email]>
>> wrote:
>>
>>> Hi Fawad, hi all,
>>>
>>> > Hi all,
>>> >
>>> >     I just gave a try to the latest code, well done with the Solr
>>> queries and the search integration in the user interface, that's cool!
>>> >
>>> > Thanks Stephane. :)
>>> >
>>> >     Imho the most convenient UX is the following for these widgets,
>>> something similar to this map:
>>> >
>>> >     http://carte.preference-commerce.fr/cci-fr/
>>> >
>>> >     That is:
>>> >
>>> >     - The facets can get activated from a button. When they get
>>> activated, they show up in an overlay panel on top of the map, without
>>> hiding the list.
>>> >     - The list gets displayed under the search input, in an overlay as
>>> well, and can be completely hidden on request
>>> >
>>> >
>>> > Just to clarify things, the facets here refer to the "Refine your
>>> search" area, the search input refers to the "Search in map" text input and
>>> the list refers to the map item search results. Is that right?
>>>
>>> Yes indeed,
>>>
>>> > If so, I believe, given the nature of XWiki's design with widgets to
>>> both the right and left (for the default flavor), the space is a little
>>> cramped for overlaying anything on the map. For the implementation of full
>>> screen maps, we can overlay search and facets but for the normal view, the
>>> map will become very small.
>>> >
>>> > Here is a mockup I prepared based on my understanding of your
>>> suggestions: https://up1.xwikisas.com/#SB7B5mLNnfnUVAogWTLarw
>>> > Let me know what you think?
>>>
>>> I think it's an efficient way to layout the widgets indeed. I agree the
>>> map may look cramped in case there are panels on the left and on the right,
>>> but the user typically would have an option to hide the results, ideally.
>>> There's one change I would suggest, that would be to layout the filters
>>> either as an overlay or as a replacement of the list, and to move the
>>> filter button closer to the search input. Regarding the filter position:
>>> the Airbnb search illustrated below behaves quite nicely imho (when you hit
>>> "More filters", you get a new panel on top with all the filters), what do
>>> you think?
>>>
>>>    https://up1.xwikisas.com/#zNABtIwH-Z-hSSUgFx-y4Q
>>>
>>> As for the information associated with each point or area, we have
>>> several options: either place it in popups on top of the map like Airbnb,
>>> or have it in the search result area, like what Google Maps proposes, or
>>> display it in a lateral panel like GoGoCarto. I would opt for popups by
>>> default, and if possible later on, leave the option to display it in the
>>> search area in case of large content, what do you think? Ideally, the panel
>>> for displaying this information would be a template that could be easily
>>> styled and customized for each map?
>>>
>>> > I have also come up with an idea to generalize the museum maps import
>>> and export you created, Stephane. We could have a standard form of wikidata
>>> query with some extra custom parameters for each location like the
>>> MuseumClass in the Museums' case. These extra parameter will be checked in
>>> JSON and classes will be created if required so that objects can be
>>> associated to each map item and then later facets can be used based upon
>>> these newly created classes.
>>> > WDYT?
>>>
>>> I think that'd be a nice feature generally speaking to ease the import
>>> of Wikidata into XWiki indeed, I have a side project on which I'm
>>> considering such developments as well, not sure yet about the outcome. If
>>> you feel like it will be useful for generating more demo maps, I'd say
>>> that'd be good indeed, but with the caveat of not digging too much in that
>>> direction for not hampering the map development of course.
>>>
>>> > Also, due to unprecedented circumstances within college, my exams have
>>> been delayed for this week and will start from next week. So I will be
>>> working this whole week on the project as opposed to what I told earlier.
>>>
>>> Ok, thank you for letting us know.
>>>
>>> I'd say at this stage that'd be great to keep progressing on functional
>>> testing automation and to finalize and release 1.0, I guess we're in tune
>>> but, as you did since the beginning, don't hesitate to raise questions
>>> about the priorities and the next steps of course.
>>>
>>> Wishing you good work days ahead,
>>>
>>> Cheers
>>>
>>> Stéphane
>>>
>>>
>>> > Best,
>>> > Fawad
>>> >
>>> >
>>> > On Mon, Jun 17, 2019 at 11:04 PM Stéphane Laurière <
>>> [hidden email] <mailto:[hidden email]>> wrote:
>>> >
>>> >     Hi Fawad, Caty, all,
>>> >
>>> >      > Hi all,
>>> >      > Hoping that everything is going well.
>>> >      >
>>> >      > Stephane, I was able to do implement most of your suggestions
>>> except the search results list.
>>> >
>>> >     I just gave a try to the latest code, well done with the Solr
>>> queries and the search integration in the user interface, that's cool!
>>> >
>>> >      > I am not too sure where I should place it. As per the latest
>>> build, the filter widget appears to the left. Do you think it is practical
>>> that we replace this widget with the search results when the user wants to
>>> see the search results and show the widget back again when the user clicks
>>> on the widget control? I am not too sure what approach I should choose here
>>> in terms of UX.
>>> >      > Ecaterina, your views on this would help a lot. Thanks. :)
>>> >
>>> >     Imho the most convenient UX is the following for these widgets,
>>> something similar to this map:
>>> >
>>> >     http://carte.preference-commerce.fr/cci-fr/
>>> >
>>> >     That is:
>>> >
>>> >     - The facets can get activated from a button. When they get
>>> activated, they show up in an overlay panel on top of the map, without
>>> hiding the list.
>>> >     - The list gets displayed under the search input, in an overlay as
>>> well, and can be completely hidden on request
>>> >
>>> >     It's rather close to what Google Maps proposes as well, except
>>> that the facets replace the list in that case (when hitting "Autres
>>> filtres"), which is a bit less convenient in my opinion, but not a big deal:
>>> >
>>> >
>>> https://www.google.com/maps/search/Restaurants/@48.865957,2.352974,16z
>>> >
>>> >     What do you think?
>>> >
>>> >      > Also, do you foresee the map to take full browser height and
>>> width as is seen in all the examples you gave me?
>>> >
>>> >     That would be a nice feature to have a button on the map to turn
>>> it full-screen indeed, similarly to what happens with the XWiki text editor.
>>> >
>>> >     Cheers
>>> >
>>> >     Stéphane
>>> >
>>> >      > Regarding the release, I will try preparing everything by
>>> tonight so that it is available for your review, including the demo tests
>>> that Vincent suggested.
>>> >      >
>>> >      > Best,
>>> >      > Fawad
>>> >      >
>>> >      >
>>> >      > On Thu, Jun 13, 2019 at 12:59 PM Stéphane Laurière <
>>> [hidden email] <mailto:[hidden email]> <mailto:
>>> [hidden email] <mailto:[hidden email]>>> wrote:
>>> >
>>>
>>>
>>> --
>>> Stéphane Laurière
>>> XWiki – https://xwiki.com
>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Ecaterina Moraru (Valica)
On Wed, Jun 19, 2019 at 11:30 PM Fawad Ali <[hidden email]> wrote:

> Hi Caty, Stephane and all,
> Hope you are all well.
>
> Stephane, your suggestions regarding the filter and search are great but I
> feel the flow of our application is more inclined towards what Ecaterina
> proposes. I will try implementing the mockups.
>
> One problem we have though is that both our facets and search lead to a
> reload of all the content inside the page asynchronously which means any
> changes made through frontend are lost (like active dropdowns etc.). We
> need to fix this.
> Do you think I will have to redo both as a separate JSON service? I can
> think of a way for search but facets are a little confusing.
> Also, we still haven't found a way to fix the $facetDisplayer problem.
> (
> https://github.com/xwiki-contrib/application-interactive-maps/blob/master/application-interactive-maps-ui/src/main/resources/Maps/Code/CommonMacros.xml#L221
> )
> How do you think we should proceed with this?
>
> Regarding the tests, I will start preparing them as soon as I am done with
> implementing the new search and facets UI.
> However, I do have confusion as to what kind of functional tests I should
> perform. I am listing some that I have in mind.
> - Map is created properly
> - Facets are working
> - Search returns expected results
> - Popup works fine
> And other similar functions.
> I will need some guidance as to how I should take a start since I have not
> actually made tests for real applications.
> After analyzing some of the tests that Vincent and Ecaterina have shared,
> I think we have to perform user actions programmatically and check to see
> if the output we are receiving is correct. Is that right?
>

You can read more details about the tests in the documentation
https://dev.xwiki.org/xwiki/bin/view/Community/Testing/#HSelenium2-basedFramework
You should first start by making the setup: download the Firefox 32 (I know
is an older version, but is the one used by our agents)
https://dev.xwiki.org/xwiki/bin/view/Community/Testing/#HBrowserversion and
try to run the existing tests for the applications. After you see them in
actions it will be much easier to understand a flow of a test and the page
objects needed. There is also this page
https://dev.xwiki.org/xwiki/bin/view/Onboarding/TrackTests/ with some
links. We have more tests in platform and in the main modules (if you will
need more examples) but start simple.

Having automated tests makes sure the functionality still works after
changes and reduced the need for manual testing. If you haven't written
tests before I'm sure you will find quite fun to see the test run live :)

Thanks,
Caty


>
> Thanks,
> Fawad
>
>
>
> On Wed, Jun 19, 2019 at 9:36 PM Ecaterina Moraru (Valica) <
> [hidden email]> wrote:
>
>> Regarding tests, there are some contrib apps with tests:
>>
>> https://github.com/xwiki-contrib/application-forum/tree/master/application-forum-test
>>
>> https://github.com/xwiki-contrib/application-tour/tree/master/application-tour-test
>>
>> Good luck with your exams,
>> Caty
>>
>> On Wed, Jun 19, 2019 at 7:32 PM Ecaterina Moraru (Valica) <
>> [hidden email]> wrote:
>>
>>> Hi,
>>>
>>> How about:
>>> * Maximizing the app area by removing the right panels;
>>> * Have the map take all the available space
>>> https://up1.xwikisas.com/#CnVVQ4JOC1ZPzAHSSbyAaQ
>>>   * Controls: Search, Full Screen, Zoom
>>>
>>> * If the user want to search
>>> https://up1.xwikisas.com/#UYDXywBeRfcwLX6d06NVtA
>>>   * expand the search control: allow input and facets using an overlay
>>>
>>> * If the user has results
>>> https://up1.xwikisas.com/#LoeVbE9idboPvoG2w3dE0Q
>>>   * display using overlay. center map on result click
>>>   * allow further filtering through facets
>>>
>>> These are just ideas, maybe there are other solutions.
>>> Thanks,
>>> Caty
>>>
>>>
>>> On Wed, Jun 19, 2019 at 6:59 PM Stéphane Laurière <[hidden email]>
>>> wrote:
>>>
>>>> Hi Fawad, hi all,
>>>>
>>>> > Hi all,
>>>> >
>>>> >     I just gave a try to the latest code, well done with the Solr
>>>> queries and the search integration in the user interface, that's cool!
>>>> >
>>>> > Thanks Stephane. :)
>>>> >
>>>> >     Imho the most convenient UX is the following for these widgets,
>>>> something similar to this map:
>>>> >
>>>> >     http://carte.preference-commerce.fr/cci-fr/
>>>> >
>>>> >     That is:
>>>> >
>>>> >     - The facets can get activated from a button. When they get
>>>> activated, they show up in an overlay panel on top of the map, without
>>>> hiding the list.
>>>> >     - The list gets displayed under the search input, in an overlay
>>>> as well, and can be completely hidden on request
>>>> >
>>>> >
>>>> > Just to clarify things, the facets here refer to the "Refine your
>>>> search" area, the search input refers to the "Search in map" text input and
>>>> the list refers to the map item search results. Is that right?
>>>>
>>>> Yes indeed,
>>>>
>>>> > If so, I believe, given the nature of XWiki's design with widgets to
>>>> both the right and left (for the default flavor), the space is a little
>>>> cramped for overlaying anything on the map. For the implementation of full
>>>> screen maps, we can overlay search and facets but for the normal view, the
>>>> map will become very small.
>>>> >
>>>> > Here is a mockup I prepared based on my understanding of your
>>>> suggestions: https://up1.xwikisas.com/#SB7B5mLNnfnUVAogWTLarw
>>>> > Let me know what you think?
>>>>
>>>> I think it's an efficient way to layout the widgets indeed. I agree the
>>>> map may look cramped in case there are panels on the left and on the right,
>>>> but the user typically would have an option to hide the results, ideally.
>>>> There's one change I would suggest, that would be to layout the filters
>>>> either as an overlay or as a replacement of the list, and to move the
>>>> filter button closer to the search input. Regarding the filter position:
>>>> the Airbnb search illustrated below behaves quite nicely imho (when you hit
>>>> "More filters", you get a new panel on top with all the filters), what do
>>>> you think?
>>>>
>>>>    https://up1.xwikisas.com/#zNABtIwH-Z-hSSUgFx-y4Q
>>>>
>>>> As for the information associated with each point or area, we have
>>>> several options: either place it in popups on top of the map like Airbnb,
>>>> or have it in the search result area, like what Google Maps proposes, or
>>>> display it in a lateral panel like GoGoCarto. I would opt for popups by
>>>> default, and if possible later on, leave the option to display it in the
>>>> search area in case of large content, what do you think? Ideally, the panel
>>>> for displaying this information would be a template that could be easily
>>>> styled and customized for each map?
>>>>
>>>> > I have also come up with an idea to generalize the museum maps import
>>>> and export you created, Stephane. We could have a standard form of wikidata
>>>> query with some extra custom parameters for each location like the
>>>> MuseumClass in the Museums' case. These extra parameter will be checked in
>>>> JSON and classes will be created if required so that objects can be
>>>> associated to each map item and then later facets can be used based upon
>>>> these newly created classes.
>>>> > WDYT?
>>>>
>>>> I think that'd be a nice feature generally speaking to ease the import
>>>> of Wikidata into XWiki indeed, I have a side project on which I'm
>>>> considering such developments as well, not sure yet about the outcome. If
>>>> you feel like it will be useful for generating more demo maps, I'd say
>>>> that'd be good indeed, but with the caveat of not digging too much in that
>>>> direction for not hampering the map development of course.
>>>>
>>>> > Also, due to unprecedented circumstances within college, my exams
>>>> have been delayed for this week and will start from next week. So I will be
>>>> working this whole week on the project as opposed to what I told earlier.
>>>>
>>>> Ok, thank you for letting us know.
>>>>
>>>> I'd say at this stage that'd be great to keep progressing on functional
>>>> testing automation and to finalize and release 1.0, I guess we're in tune
>>>> but, as you did since the beginning, don't hesitate to raise questions
>>>> about the priorities and the next steps of course.
>>>>
>>>> Wishing you good work days ahead,
>>>>
>>>> Cheers
>>>>
>>>> Stéphane
>>>>
>>>>
>>>> > Best,
>>>> > Fawad
>>>> >
>>>> >
>>>> > On Mon, Jun 17, 2019 at 11:04 PM Stéphane Laurière <
>>>> [hidden email] <mailto:[hidden email]>> wrote:
>>>> >
>>>> >     Hi Fawad, Caty, all,
>>>> >
>>>> >      > Hi all,
>>>> >      > Hoping that everything is going well.
>>>> >      >
>>>> >      > Stephane, I was able to do implement most of your suggestions
>>>> except the search results list.
>>>> >
>>>> >     I just gave a try to the latest code, well done with the Solr
>>>> queries and the search integration in the user interface, that's cool!
>>>> >
>>>> >      > I am not too sure where I should place it. As per the latest
>>>> build, the filter widget appears to the left. Do you think it is practical
>>>> that we replace this widget with the search results when the user wants to
>>>> see the search results and show the widget back again when the user clicks
>>>> on the widget control? I am not too sure what approach I should choose here
>>>> in terms of UX.
>>>> >      > Ecaterina, your views on this would help a lot. Thanks. :)
>>>> >
>>>> >     Imho the most convenient UX is the following for these widgets,
>>>> something similar to this map:
>>>> >
>>>> >     http://carte.preference-commerce.fr/cci-fr/
>>>> >
>>>> >     That is:
>>>> >
>>>> >     - The facets can get activated from a button. When they get
>>>> activated, they show up in an overlay panel on top of the map, without
>>>> hiding the list.
>>>> >     - The list gets displayed under the search input, in an overlay
>>>> as well, and can be completely hidden on request
>>>> >
>>>> >     It's rather close to what Google Maps proposes as well, except
>>>> that the facets replace the list in that case (when hitting "Autres
>>>> filtres"), which is a bit less convenient in my opinion, but not a big deal:
>>>> >
>>>> >
>>>> https://www.google.com/maps/search/Restaurants/@48.865957,2.352974,16z
>>>> >
>>>> >     What do you think?
>>>> >
>>>> >      > Also, do you foresee the map to take full browser height and
>>>> width as is seen in all the examples you gave me?
>>>> >
>>>> >     That would be a nice feature to have a button on the map to turn
>>>> it full-screen indeed, similarly to what happens with the XWiki text editor.
>>>> >
>>>> >     Cheers
>>>> >
>>>> >     Stéphane
>>>> >
>>>> >      > Regarding the release, I will try preparing everything by
>>>> tonight so that it is available for your review, including the demo tests
>>>> that Vincent suggested.
>>>> >      >
>>>> >      > Best,
>>>> >      > Fawad
>>>> >      >
>>>> >      >
>>>> >      > On Thu, Jun 13, 2019 at 12:59 PM Stéphane Laurière <
>>>> [hidden email] <mailto:[hidden email]> <mailto:
>>>> [hidden email] <mailto:[hidden email]>>> wrote:
>>>> >
>>>>
>>>>
>>>> --
>>>> Stéphane Laurière
>>>> XWiki – https://xwiki.com
>>>>
>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi Stephane, Caty and all,
Hope you are doing great.

I have deployed a test case for map creation. I would like you to have a
look at it. It works fine upto the commented code.
There is one problem I am facing which is, during the last part, the marker
does not load up. If I restart the same XWiki instance from the target
folder and go to the page created during the test, the marker appears
perfectly. I am not sure what's wrong.
And one time I tried the test, the marker did appear during the test and
then I ran the test again without changing anything but the marker did not
show up. I am using wait but it does not seem to be the problem with
javascript. It appears that the map is not getting the rendered data from
velocity and again I am not sure why when it works perfectly if I view the
same page outside of test.

I would also like your review on the new search and fullscreen controls.

Thanks,
Fawad


On Thu, Jun 20, 2019 at 2:41 PM Ecaterina Moraru (Valica) <[hidden email]>
wrote:

>
>
> On Wed, Jun 19, 2019 at 11:30 PM Fawad Ali <[hidden email]>
> wrote:
>
>> Hi Caty, Stephane and all,
>> Hope you are all well.
>>
>> Stephane, your suggestions regarding the filter and search are great but
>> I feel the flow of our application is more inclined towards what Ecaterina
>> proposes. I will try implementing the mockups.
>>
>> One problem we have though is that both our facets and search lead to a
>> reload of all the content inside the page asynchronously which means any
>> changes made through frontend are lost (like active dropdowns etc.). We
>> need to fix this.
>> Do you think I will have to redo both as a separate JSON service? I can
>> think of a way for search but facets are a little confusing.
>> Also, we still haven't found a way to fix the $facetDisplayer problem.
>> (
>> https://github.com/xwiki-contrib/application-interactive-maps/blob/master/application-interactive-maps-ui/src/main/resources/Maps/Code/CommonMacros.xml#L221
>> )
>> How do you think we should proceed with this?
>>
>> Regarding the tests, I will start preparing them as soon as I am done
>> with implementing the new search and facets UI.
>> However, I do have confusion as to what kind of functional tests I should
>> perform. I am listing some that I have in mind.
>> - Map is created properly
>> - Facets are working
>> - Search returns expected results
>> - Popup works fine
>> And other similar functions.
>> I will need some guidance as to how I should take a start since I have
>> not actually made tests for real applications.
>> After analyzing some of the tests that Vincent and Ecaterina have shared,
>> I think we have to perform user actions programmatically and check to see
>> if the output we are receiving is correct. Is that right?
>>
>
> You can read more details about the tests in the documentation
> https://dev.xwiki.org/xwiki/bin/view/Community/Testing/#HSelenium2-basedFramework
> You should first start by making the setup: download the Firefox 32 (I
> know is an older version, but is the one used by our agents)
> https://dev.xwiki.org/xwiki/bin/view/Community/Testing/#HBrowserversion
> and try to run the existing tests for the applications. After you see them
> in actions it will be much easier to understand a flow of a test and the
> page objects needed. There is also this page
> https://dev.xwiki.org/xwiki/bin/view/Onboarding/TrackTests/ with some
> links. We have more tests in platform and in the main modules (if you will
> need more examples) but start simple.
>
> Having automated tests makes sure the functionality still works after
> changes and reduced the need for manual testing. If you haven't written
> tests before I'm sure you will find quite fun to see the test run live :)
>
> Thanks,
> Caty
>
>
>>
>> Thanks,
>> Fawad
>>
>>
>>
>> On Wed, Jun 19, 2019 at 9:36 PM Ecaterina Moraru (Valica) <
>> [hidden email]> wrote:
>>
>>> Regarding tests, there are some contrib apps with tests:
>>>
>>> https://github.com/xwiki-contrib/application-forum/tree/master/application-forum-test
>>>
>>> https://github.com/xwiki-contrib/application-tour/tree/master/application-tour-test
>>>
>>> Good luck with your exams,
>>> Caty
>>>
>>> On Wed, Jun 19, 2019 at 7:32 PM Ecaterina Moraru (Valica) <
>>> [hidden email]> wrote:
>>>
>>>> Hi,
>>>>
>>>> How about:
>>>> * Maximizing the app area by removing the right panels;
>>>> * Have the map take all the available space
>>>> https://up1.xwikisas.com/#CnVVQ4JOC1ZPzAHSSbyAaQ
>>>>   * Controls: Search, Full Screen, Zoom
>>>>
>>>> * If the user want to search
>>>> https://up1.xwikisas.com/#UYDXywBeRfcwLX6d06NVtA
>>>>   * expand the search control: allow input and facets using an overlay
>>>>
>>>> * If the user has results
>>>> https://up1.xwikisas.com/#LoeVbE9idboPvoG2w3dE0Q
>>>>   * display using overlay. center map on result click
>>>>   * allow further filtering through facets
>>>>
>>>> These are just ideas, maybe there are other solutions.
>>>> Thanks,
>>>> Caty
>>>>
>>>>
>>>> On Wed, Jun 19, 2019 at 6:59 PM Stéphane Laurière <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Fawad, hi all,
>>>>>
>>>>> > Hi all,
>>>>> >
>>>>> >     I just gave a try to the latest code, well done with the Solr
>>>>> queries and the search integration in the user interface, that's cool!
>>>>> >
>>>>> > Thanks Stephane. :)
>>>>> >
>>>>> >     Imho the most convenient UX is the following for these widgets,
>>>>> something similar to this map:
>>>>> >
>>>>> >     http://carte.preference-commerce.fr/cci-fr/
>>>>> >
>>>>> >     That is:
>>>>> >
>>>>> >     - The facets can get activated from a button. When they get
>>>>> activated, they show up in an overlay panel on top of the map, without
>>>>> hiding the list.
>>>>> >     - The list gets displayed under the search input, in an overlay
>>>>> as well, and can be completely hidden on request
>>>>> >
>>>>> >
>>>>> > Just to clarify things, the facets here refer to the "Refine your
>>>>> search" area, the search input refers to the "Search in map" text input and
>>>>> the list refers to the map item search results. Is that right?
>>>>>
>>>>> Yes indeed,
>>>>>
>>>>> > If so, I believe, given the nature of XWiki's design with widgets to
>>>>> both the right and left (for the default flavor), the space is a little
>>>>> cramped for overlaying anything on the map. For the implementation of full
>>>>> screen maps, we can overlay search and facets but for the normal view, the
>>>>> map will become very small.
>>>>> >
>>>>> > Here is a mockup I prepared based on my understanding of your
>>>>> suggestions: https://up1.xwikisas.com/#SB7B5mLNnfnUVAogWTLarw
>>>>> > Let me know what you think?
>>>>>
>>>>> I think it's an efficient way to layout the widgets indeed. I agree
>>>>> the map may look cramped in case there are panels on the left and on the
>>>>> right, but the user typically would have an option to hide the results,
>>>>> ideally. There's one change I would suggest, that would be to layout the
>>>>> filters either as an overlay or as a replacement of the list, and to move
>>>>> the filter button closer to the search input. Regarding the filter
>>>>> position: the Airbnb search illustrated below behaves quite nicely imho
>>>>> (when you hit "More filters", you get a new panel on top with all the
>>>>> filters), what do you think?
>>>>>
>>>>>    https://up1.xwikisas.com/#zNABtIwH-Z-hSSUgFx-y4Q
>>>>>
>>>>> As for the information associated with each point or area, we have
>>>>> several options: either place it in popups on top of the map like Airbnb,
>>>>> or have it in the search result area, like what Google Maps proposes, or
>>>>> display it in a lateral panel like GoGoCarto. I would opt for popups by
>>>>> default, and if possible later on, leave the option to display it in the
>>>>> search area in case of large content, what do you think? Ideally, the panel
>>>>> for displaying this information would be a template that could be easily
>>>>> styled and customized for each map?
>>>>>
>>>>> > I have also come up with an idea to generalize the museum maps
>>>>> import and export you created, Stephane. We could have a standard form of
>>>>> wikidata query with some extra custom parameters for each location like the
>>>>> MuseumClass in the Museums' case. These extra parameter will be checked in
>>>>> JSON and classes will be created if required so that objects can be
>>>>> associated to each map item and then later facets can be used based upon
>>>>> these newly created classes.
>>>>> > WDYT?
>>>>>
>>>>> I think that'd be a nice feature generally speaking to ease the import
>>>>> of Wikidata into XWiki indeed, I have a side project on which I'm
>>>>> considering such developments as well, not sure yet about the outcome. If
>>>>> you feel like it will be useful for generating more demo maps, I'd say
>>>>> that'd be good indeed, but with the caveat of not digging too much in that
>>>>> direction for not hampering the map development of course.
>>>>>
>>>>> > Also, due to unprecedented circumstances within college, my exams
>>>>> have been delayed for this week and will start from next week. So I will be
>>>>> working this whole week on the project as opposed to what I told earlier.
>>>>>
>>>>> Ok, thank you for letting us know.
>>>>>
>>>>> I'd say at this stage that'd be great to keep progressing on
>>>>> functional testing automation and to finalize and release 1.0, I guess
>>>>> we're in tune but, as you did since the beginning, don't hesitate to raise
>>>>> questions about the priorities and the next steps of course.
>>>>>
>>>>> Wishing you good work days ahead,
>>>>>
>>>>> Cheers
>>>>>
>>>>> Stéphane
>>>>>
>>>>>
>>>>> > Best,
>>>>> > Fawad
>>>>> >
>>>>> >
>>>>> > On Mon, Jun 17, 2019 at 11:04 PM Stéphane Laurière <
>>>>> [hidden email] <mailto:[hidden email]>> wrote:
>>>>> >
>>>>> >     Hi Fawad, Caty, all,
>>>>> >
>>>>> >      > Hi all,
>>>>> >      > Hoping that everything is going well.
>>>>> >      >
>>>>> >      > Stephane, I was able to do implement most of your suggestions
>>>>> except the search results list.
>>>>> >
>>>>> >     I just gave a try to the latest code, well done with the Solr
>>>>> queries and the search integration in the user interface, that's cool!
>>>>> >
>>>>> >      > I am not too sure where I should place it. As per the latest
>>>>> build, the filter widget appears to the left. Do you think it is practical
>>>>> that we replace this widget with the search results when the user wants to
>>>>> see the search results and show the widget back again when the user clicks
>>>>> on the widget control? I am not too sure what approach I should choose here
>>>>> in terms of UX.
>>>>> >      > Ecaterina, your views on this would help a lot. Thanks. :)
>>>>> >
>>>>> >     Imho the most convenient UX is the following for these widgets,
>>>>> something similar to this map:
>>>>> >
>>>>> >     http://carte.preference-commerce.fr/cci-fr/
>>>>> >
>>>>> >     That is:
>>>>> >
>>>>> >     - The facets can get activated from a button. When they get
>>>>> activated, they show up in an overlay panel on top of the map, without
>>>>> hiding the list.
>>>>> >     - The list gets displayed under the search input, in an overlay
>>>>> as well, and can be completely hidden on request
>>>>> >
>>>>> >     It's rather close to what Google Maps proposes as well, except
>>>>> that the facets replace the list in that case (when hitting "Autres
>>>>> filtres"), which is a bit less convenient in my opinion, but not a big deal:
>>>>> >
>>>>> >
>>>>> https://www.google.com/maps/search/Restaurants/@48.865957,2.352974,16z
>>>>> >
>>>>> >     What do you think?
>>>>> >
>>>>> >      > Also, do you foresee the map to take full browser height and
>>>>> width as is seen in all the examples you gave me?
>>>>> >
>>>>> >     That would be a nice feature to have a button on the map to turn
>>>>> it full-screen indeed, similarly to what happens with the XWiki text editor.
>>>>> >
>>>>> >     Cheers
>>>>> >
>>>>> >     Stéphane
>>>>> >
>>>>> >      > Regarding the release, I will try preparing everything by
>>>>> tonight so that it is available for your review, including the demo tests
>>>>> that Vincent suggested.
>>>>> >      >
>>>>> >      > Best,
>>>>> >      > Fawad
>>>>> >      >
>>>>> >      >
>>>>> >      > On Thu, Jun 13, 2019 at 12:59 PM Stéphane Laurière <
>>>>> [hidden email] <mailto:[hidden email]> <mailto:
>>>>> [hidden email] <mailto:[hidden email]>>> wrote:
>>>>> >
>>>>>
>>>>>
>>>>> --
>>>>> Stéphane Laurière
>>>>> XWiki – https://xwiki.com
>>>>>
>>>>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
In reply to this post by Fawad Ali
Hi Fawad, Caty, all,

Apologies for the delay. Meantime, I confirm that Caty and I filled in the 1st GSoC evaluation for the period, with very positive appreciations. Thumbs up Fawad, and good luck with the next steps.

Fawad Ali:
> Hi Caty, Stephane and all,
> Hope you are all well.
>
> Stephane, your suggestions regarding the filter and search are great but I
> feel the flow of our application is more inclined towards what Ecaterina
> proposes. I will try implementing the mockups.

That's very helpful to have mockups indeed to align the visions. Their flow is actually completely in line with what I have in mind as well (except I may prefer personaly to have the facet above the result list items, to be discussed...), and I see in the latest version (of today) that you made good progress toward that direction. The fullscreen widget is cool and works fine. I would expect the search button to be closer to the area where the widget pops in, that is on the left side in our current setup, what do you think?
 
> One problem we have though is that both our facets and search lead to a
> reload of all the content inside the page asynchronously which means any
> changes made through frontend are lost (like active dropdowns etc.). We
> need to fix this.
> Do you think I will have to redo both as a separate JSON service? I can
> think of a way for search but facets are a little confusing.

Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves similarly as far as I understand, and manages to keep the facets in the same state visually as how they were before launching the asychronous call, doesn't it? So I was thinking we could use the same approach, or is there a hidden complexity? As for the search input: the input itself can be retrieved from the URL, so we should be able to restore it as well, don't we? Can you clarify how separating in two distinct services may help? We will need to consider the other states of the map that we want to represent in the URL so that specific map states can be shared easily, we could add the current selection to the URL's fragment, what do you think?

> Also, we still haven't found a way to fix the $facetDisplayer problem.
> (
> https://github.com/xwiki-contrib/application-interactive-maps/blob/master/application-interactive-maps-ui/src/main/resources/Maps/Code/CommonMacros.xml#L221
> )
> How do you think we should proceed with this?

We came up with a possible workaround with Anca, which consists in using the Velocity "evaluate" macro in order to force the usage of the current Velocity context (replace "scriptPage" by "facetDisplayer"):

   #set ($script = $!scriptPage.content.replaceAll('\{\{/{0,2}velocity\}\}', ''))
   #evaluate($script)

I gave a try to this solution and it worked fine on my end on the example mentioned on the forum (not tested yet with the facetDisplayers). We need to investigate further though:

   https://forum.xwiki.org/t/including-code-dynamically-from-a-sheet/5085/3

> Regarding the tests, I will start preparing them as soon as I am done with
> implementing the new search and facets UI.
> However, I do have confusion as to what kind of functional tests I should
> perform. I am listing some that I have in mind.
> - Map is created properly
> - Facets are working
> - Search returns expected results
> - Popup works fine
> And other similar functions.
> I will need some guidance as to how I should take a start since I have not
> actually made tests for real applications.
> After analyzing some of the tests that Vincent and Ecaterina have shared, I
> think we have to perform user actions programmatically and check to see if
> the output we are receiving is correct. Is that right?

I need to look more into the testing framework including the pointers and examples provided by Vincent and Caty, and to go through the steps you mention in your mail dated from 24/6, I'll get back to you on this.

Cheers

Stéphane

 
> Thanks,
> Fawad

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi everyone,
Hope to find you well.

Their flow is actually completely in line with what I have in mind as well
> (except I may prefer personaly to have the facet above the result list
> items, to be discussed...)
>

That would certainly be better in my opinion.

I would expect the search button to be closer to the area where the widget
> pops in, that is on the left side in our current setup, what do you think?


It was that way in the previous commits. But the idea of this approach is
to have the left side completely blank with no controls. What it helps in
is to provide a dedicated space for both the popup and search widget. If we
place the search control on the top left, our search control is hidden when
either popup or the search widget is enabled. And if we place the search
widget right beside the search control (to the right of it), it will take
unnecessary space.
One option is to have the close icon to the right of the search widget
popup but it still doesn't fix the problem of search control hiding when
the marker popup is opened.

Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves

> similarly as far as I understand, and manages to keep the facets in the
> same state visually as how they were before launching the asychronous call,
> doesn't it? So I was thinking we could use the same approach, or is there a
> hidden complexity? As for the search input: the input itself can be
> retrieved from the URL, so we should be able to restore it as well, don't
> we? Can you clarify how separating in two distinct services may help? We
> will need to consider the other states of the map that we want to represent
> in the URL so that specific map states can be shared easily, we could add
> the current selection to the URL's fragment, what do you think?
>

That's exactly what I eventually had in mind besides the JSON service. For
the JSON service, we could have a common place for retrieving any kind of
map data, like a REST API but that was the secondary approach.
What we could do now is utilize the URL parameters. For now, I am thinking
of having a multiple URL parameter that can contain different states of the
map. For example, if we have both the fullscreen and search popup enabled,
we could have the URL parameters "?mfullscreen=true&msearchw=true" where
mfullscreen = map full screen and msearchw = map search widget. Other
parameters like this can be added for different states. WDYT?

We came up with a possible workaround with Anca, which consists in using

> the Velocity "evaluate" macro in order to force the usage of the current
> Velocity context (replace "scriptPage" by "facetDisplayer"):
>
>    #set ($script =
> $!scriptPage.content.replaceAll('\{\{/{0,2}velocity\}\}', ''))
>    #evaluate($script)
>
> I gave a try to this solution and it worked fine on my end on the example
> mentioned on the forum (not tested yet with the facetDisplayers). We need
> to investigate further though:


That's great, I will check it out as soon as I am able.

Best,
Fawad

On Fri, Jun 28, 2019 at 3:02 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad, Caty, all,
>
> Apologies for the delay. Meantime, I confirm that Caty and I filled in the
> 1st GSoC evaluation for the period, with very positive appreciations.
> Thumbs up Fawad, and good luck with the next steps.
>
> Fawad Ali:
> > Hi Caty, Stephane and all,
> > Hope you are all well.
> >
> > Stephane, your suggestions regarding the filter and search are great but
> I
> > feel the flow of our application is more inclined towards what Ecaterina
> > proposes. I will try implementing the mockups.
>
> That's very helpful to have mockups indeed to align the visions. Their
> flow is actually completely in line with what I have in mind as well
> (except I may prefer personaly to have the facet above the result list
> items, to be discussed...), and I see in the latest version (of today) that
> you made good progress toward that direction. The fullscreen widget is cool
> and works fine. I would expect the search button to be closer to the area
> where the widget pops in, that is on the left side in our current setup,
> what do you think?
>
> > One problem we have though is that both our facets and search lead to a
> > reload of all the content inside the page asynchronously which means any
> > changes made through frontend are lost (like active dropdowns etc.). We
> > need to fix this.
> > Do you think I will have to redo both as a separate JSON service? I can
> > think of a way for search but facets are a little confusing.
>
> Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves
> similarly as far as I understand, and manages to keep the facets in the
> same state visually as how they were before launching the asychronous call,
> doesn't it? So I was thinking we could use the same approach, or is there a
> hidden complexity? As for the search input: the input itself can be
> retrieved from the URL, so we should be able to restore it as well, don't
> we? Can you clarify how separating in two distinct services may help? We
> will need to consider the other states of the map that we want to represent
> in the URL so that specific map states can be shared easily, we could add
> the current selection to the URL's fragment, what do you think?
>
> > Also, we still haven't found a way to fix the $facetDisplayer problem.
> > (
> >
> https://github.com/xwiki-contrib/application-interactive-maps/blob/master/application-interactive-maps-ui/src/main/resources/Maps/Code/CommonMacros.xml#L221
> > )
> > How do you think we should proceed with this?
>
> We came up with a possible workaround with Anca, which consists in using
> the Velocity "evaluate" macro in order to force the usage of the current
> Velocity context (replace "scriptPage" by "facetDisplayer"):
>
>    #set ($script =
> $!scriptPage.content.replaceAll('\{\{/{0,2}velocity\}\}', ''))
>    #evaluate($script)
>
> I gave a try to this solution and it worked fine on my end on the example
> mentioned on the forum (not tested yet with the facetDisplayers). We need
> to investigate further though:
>
>
> https://forum.xwiki.org/t/including-code-dynamically-from-a-sheet/5085/3
>
> > Regarding the tests, I will start preparing them as soon as I am done
> with
> > implementing the new search and facets UI.
> > However, I do have confusion as to what kind of functional tests I should
> > perform. I am listing some that I have in mind.
> > - Map is created properly
> > - Facets are working
> > - Search returns expected results
> > - Popup works fine
> > And other similar functions.
> > I will need some guidance as to how I should take a start since I have
> not
> > actually made tests for real applications.
> > After analyzing some of the tests that Vincent and Ecaterina have
> shared, I
> > think we have to perform user actions programmatically and check to see
> if
> > the output we are receiving is correct. Is that right?
>
> I need to look more into the testing framework including the pointers and
> examples provided by Vincent and Caty, and to go through the steps you
> mention in your mail dated from 24/6, I'll get back to you on this.
>
> Cheers
>
> Stéphane
>
>
> > Thanks,
> > Fawad
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi all,
Hope everyone is well.

Please review the application developed so far. I have included a UI test
and map states. I think we should release the application as soon as we can
so that user reviews can be gathered.

Best,
Fawad

On Mon, Jul 1, 2019, 8:26 PM Fawad Ali <[hidden email]> wrote:

> Hi everyone,
> Hope to find you well.
>
> Their flow is actually completely in line with what I have in mind as well
>> (except I may prefer personaly to have the facet above the result list
>> items, to be discussed...)
>>
>
> That would certainly be better in my opinion.
>
> I would expect the search button to be closer to the area where the widget
>> pops in, that is on the left side in our current setup, what do you think?
>
>
> It was that way in the previous commits. But the idea of this approach is
> to have the left side completely blank with no controls. What it helps in
> is to provide a dedicated space for both the popup and search widget. If we
> place the search control on the top left, our search control is hidden when
> either popup or the search widget is enabled. And if we place the search
> widget right beside the search control (to the right of it), it will take
> unnecessary space.
> One option is to have the close icon to the right of the search widget
> popup but it still doesn't fix the problem of search control hiding when
> the marker popup is opened.
>
> Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves
>> similarly as far as I understand, and manages to keep the facets in the
>> same state visually as how they were before launching the asychronous call,
>> doesn't it? So I was thinking we could use the same approach, or is there a
>> hidden complexity? As for the search input: the input itself can be
>> retrieved from the URL, so we should be able to restore it as well, don't
>> we? Can you clarify how separating in two distinct services may help? We
>> will need to consider the other states of the map that we want to represent
>> in the URL so that specific map states can be shared easily, we could add
>> the current selection to the URL's fragment, what do you think?
>>
>
> That's exactly what I eventually had in mind besides the JSON service. For
> the JSON service, we could have a common place for retrieving any kind of
> map data, like a REST API but that was the secondary approach.
> What we could do now is utilize the URL parameters. For now, I am thinking
> of having a multiple URL parameter that can contain different states of the
> map. For example, if we have both the fullscreen and search popup enabled,
> we could have the URL parameters "?mfullscreen=true&msearchw=true" where
> mfullscreen = map full screen and msearchw = map search widget. Other
> parameters like this can be added for different states. WDYT?
>
> We came up with a possible workaround with Anca, which consists in using
>> the Velocity "evaluate" macro in order to force the usage of the current
>> Velocity context (replace "scriptPage" by "facetDisplayer"):
>>
>>    #set ($script =
>> $!scriptPage.content.replaceAll('\{\{/{0,2}velocity\}\}', ''))
>>    #evaluate($script)
>>
>> I gave a try to this solution and it worked fine on my end on the example
>> mentioned on the forum (not tested yet with the facetDisplayers). We need
>> to investigate further though:
>
>
> That's great, I will check it out as soon as I am able.
>
> Best,
> Fawad
>
> On Fri, Jun 28, 2019 at 3:02 PM Stéphane Laurière <[hidden email]>
> wrote:
>
>> Hi Fawad, Caty, all,
>>
>> Apologies for the delay. Meantime, I confirm that Caty and I filled in
>> the 1st GSoC evaluation for the period, with very positive appreciations.
>> Thumbs up Fawad, and good luck with the next steps.
>>
>> Fawad Ali:
>> > Hi Caty, Stephane and all,
>> > Hope you are all well.
>> >
>> > Stephane, your suggestions regarding the filter and search are great
>> but I
>> > feel the flow of our application is more inclined towards what Ecaterina
>> > proposes. I will try implementing the mockups.
>>
>> That's very helpful to have mockups indeed to align the visions. Their
>> flow is actually completely in line with what I have in mind as well
>> (except I may prefer personaly to have the facet above the result list
>> items, to be discussed...), and I see in the latest version (of today) that
>> you made good progress toward that direction. The fullscreen widget is cool
>> and works fine. I would expect the search button to be closer to the area
>> where the widget pops in, that is on the left side in our current setup,
>> what do you think?
>>
>> > One problem we have though is that both our facets and search lead to a
>> > reload of all the content inside the page asynchronously which means any
>> > changes made through frontend are lost (like active dropdowns etc.). We
>> > need to fix this.
>> > Do you think I will have to redo both as a separate JSON service? I can
>> > think of a way for search but facets are a little confusing.
>>
>> Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves
>> similarly as far as I understand, and manages to keep the facets in the
>> same state visually as how they were before launching the asychronous call,
>> doesn't it? So I was thinking we could use the same approach, or is there a
>> hidden complexity? As for the search input: the input itself can be
>> retrieved from the URL, so we should be able to restore it as well, don't
>> we? Can you clarify how separating in two distinct services may help? We
>> will need to consider the other states of the map that we want to represent
>> in the URL so that specific map states can be shared easily, we could add
>> the current selection to the URL's fragment, what do you think?
>>
>> > Also, we still haven't found a way to fix the $facetDisplayer problem.
>> > (
>> >
>> https://github.com/xwiki-contrib/application-interactive-maps/blob/master/application-interactive-maps-ui/src/main/resources/Maps/Code/CommonMacros.xml#L221
>> > )
>> > How do you think we should proceed with this?
>>
>> We came up with a possible workaround with Anca, which consists in using
>> the Velocity "evaluate" macro in order to force the usage of the current
>> Velocity context (replace "scriptPage" by "facetDisplayer"):
>>
>>    #set ($script =
>> $!scriptPage.content.replaceAll('\{\{/{0,2}velocity\}\}', ''))
>>    #evaluate($script)
>>
>> I gave a try to this solution and it worked fine on my end on the example
>> mentioned on the forum (not tested yet with the facetDisplayers). We need
>> to investigate further though:
>>
>>
>> https://forum.xwiki.org/t/including-code-dynamically-from-a-sheet/5085/3
>>
>> > Regarding the tests, I will start preparing them as soon as I am done
>> with
>> > implementing the new search and facets UI.
>> > However, I do have confusion as to what kind of functional tests I
>> should
>> > perform. I am listing some that I have in mind.
>> > - Map is created properly
>> > - Facets are working
>> > - Search returns expected results
>> > - Popup works fine
>> > And other similar functions.
>> > I will need some guidance as to how I should take a start since I have
>> not
>> > actually made tests for real applications.
>> > After analyzing some of the tests that Vincent and Ecaterina have
>> shared, I
>> > think we have to perform user actions programmatically and check to see
>> if
>> > the output we are receiving is correct. Is that right?
>>
>> I need to look more into the testing framework including the pointers and
>> examples provided by Vincent and Caty, and to go through the steps you
>> mention in your mail dated from 24/6, I'll get back to you on this.
>>
>> Cheers
>>
>> Stéphane
>>
>>
>> > Thanks,
>> > Fawad
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
Hi Fawad,

Good to hear from you again, I hope things are fine on your end as well. Thanks for the update. Sorry for the delay, we were traveling yesterday. Releasing the application soon sounds good. I'm facing a few issues though, they may be related to an installation issue on my side, not sure. I grabbed the latest code and imported as a XAR over the existing pages in my 11.x wiki without error, and I notice the following (I'll consider posting some Jira issues if needed):

- catalina.out errors (not sure if they were present with previous version):

2019-07-10 11:34:30,349 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Error at line 203, column 85: missing variable name. Caused by: [      var index = 0, lat = 0, lng = 0, coordinates = [], shift = 0, result = 0, byte = null, latitude_change, longitude_change, factor = Math.pow(10, Number.isInteger(precision) ? precision : 5);]
2019-07-10 11:34:30,350 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Error at line 206, column 13: identifier is a reserved word. Caused [...]
2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] ERROR c.x.x.w.s.JsExtension          - Runtime error minimizing JSX object: Compilation produced 8 syntax errors.
2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Failed to compress JS extension: null

- On the UI side, possibly as a consequence, I can't see a list of results anymore, and the search widget state is not restored.

- I notice there is no default radio button checked in the search form: I think either "location" or "item" should be checked, to let the user know what's the default (I'd say "item").

- I think the name "Maps.Code.Leaflet" might be misleading for potential developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think?

- Ludovic just suggested an improvement (for the next versions): let the user configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used.

Cheers

Stéphane


Fawad Ali:
> Hi all,
> Hope everyone is well.
>
> Please review the application developed so far. I have included a UI test and map states. I think we should release the application as soon as we can so that user reviews can be gathered.
>
> Best,
> Fawad

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
I have fixed the errors you mentioned. It appears one of the variables had
a bad name which was causing the error.

On the UI side, possibly as a consequence, I can't see a list of results
> anymore, and the search widget state is not restored.


The list of results is just fine on my end, I am not sure what could be
wrong. About the map state, it does not work well with facets. Since facets
have a separate code we cannot apply custom code when a facet is selected
thus limiting our ability to pass the map state through js. I tried looking
around for related js events but could not find one through which we can
pass the map state after a facet is clicked. Do you have anything in mind
for this?

I think the name "Maps.Code.Leaflet" might be misleading for potential
> developers: this could mean this page is providing Leaflet, while it does
> not. I would suggest to choose a name that is closer to what the JavaScript
> really provides, from a functional point of view, what do you think?


I think its fine as is. Since it is placed inside the Code space, the
developers will immediately be able to know that all the Leaflet related
code resides inside it. But to be on the safe side, we can rename it to
LeafletMap as in the macro-map.

Ludovic just suggested an improvement (for the next versions): let the user
> configure which existing field could be used in an existing class for
> retrieving geographical information, that could be interesting indeed, to
> be discussed. The calendar application works this way already as far as I
> understood: it lets the user define the date / time field to be used.


Thanks Ludovic for your suggestion. I would look into the calendar
application to have a better understanding of this and let you know my
thoughts.

Best,
Fawad


On Wed, Jul 10, 2019 at 2:55 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad,
>
> Good to hear from you again, I hope things are fine on your end as well.
> Thanks for the update. Sorry for the delay, we were traveling yesterday.
> Releasing the application soon sounds good. I'm facing a few issues though,
> they may be related to an installation issue on my side, not sure. I
> grabbed the latest code and imported as a XAR over the existing pages in my
> 11.x wiki without error, and I notice the following (I'll consider posting
> some Jira issues if needed):
>
> - catalina.out errors (not sure if they were present with previous
> version):
>
> 2019-07-10 11:34:30,349 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Error at line 203, column 85:
> missing variable name. Caused by: [      var index = 0, lat = 0, lng = 0,
> coordinates = [], shift = 0, result = 0, byte = null, latitude_change,
> longitude_change, factor = Math.pow(10, Number.isInteger(precision) ?
> precision : 5);]
> 2019-07-10 11:34:30,350 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Error at line 206, column 13:
> identifier is a reserved word. Caused [...]
> 2019-07-10 11:35:02,841 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> ERROR c.x.x.w.s.JsExtension          - Runtime error minimizing JSX object:
> Compilation produced 8 syntax errors.
> 2019-07-10 11:35:02,841 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Failed to compress JS extension: null
>
> - On the UI side, possibly as a consequence, I can't see a list of results
> anymore, and the search widget state is not restored.
>
> - I notice there is no default radio button checked in the search form: I
> think either "location" or "item" should be checked, to let the user know
> what's the default (I'd say "item").
>
> - I think the name "Maps.Code.Leaflet" might be misleading for potential
> developers: this could mean this page is providing Leaflet, while it does
> not. I would suggest to choose a name that is closer to what the JavaScript
> really provides, from a functional point of view, what do you think?
>
> - Ludovic just suggested an improvement (for the next versions): let the
> user configure which existing field could be used in an existing class for
> retrieving geographical information, that could be interesting indeed, to
> be discussed. The calendar application works this way already as far as I
> understood: it lets the user define the date / time field to be used.
>
> Cheers
>
> Stéphane
>
>
> Fawad Ali:
> > Hi all,
> > Hope everyone is well.
> >
> > Please review the application developed so far. I have included a UI
> test and map states. I think we should release the application as soon as
> we can so that user reviews can be gathered.
> >
> > Best,
> > Fawad
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
Hi Fawad, all,

> I have fixed the errors you mentioned. It appears one of the variables had a bad name which was causing the error.
The error does not show anymore indeed on my end, thanks.

>     On the UI side, possibly as a consequence, I can't see a list of results anymore, and the search widget state is not restored.
>
>
> The list of results is just fine on my end, I am not sure what could be wrong.

In the meantime, I figured out that the list shows up indeed when issuing a query in the search input, cool. However, as a user I would expect the list to be present also when the search input is empty, with the possibility to reduce the list by hitting the link "Show result items", what do you think? Speaking of the list, that'd be great imho that the popups can be displayed while the list is active, so that the user can browse content via the list, wouldn't it? This should not prevent us from release version 1.0 though.

> About the map state, it does not work well with facets. Since facets have a separate code we cannot apply custom code when a facet is selected thus limiting our ability to pass the map state through js. I tried looking around for related js events but could not find one through which we can pass the map state after a facet is clicked. Do you have anything in mind for this?

Actually, with the new version, the facet state is restored as I would expect it, sorry for the confusion. Restoring the full screen is working in most cases, that's cool, however if I run a search, then enter full screen, then refine the search, it seems that the full screen state is not preserved, is it?

A note about demos: as far as I can see, the museum map demo does not showcase the "country" facet by default, don't you think that'd be worth adding it so that the user has a simple demo with facets working with custom fields?

>     I think the name "Maps.Code.Leaflet" might be misleading for potential developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think?
>
>
> I think its fine as is. Since it is placed inside the Code space, the developers will immediately be able to know that all the Leaflet related code resides inside it. But to be on the safe side, we can rename it to LeafletMap as in the macro-map.

I agree LeafletMap would be closer to what it does, but contrarily to the Macro Map, if I'm not mistaken, the page currently named Maps.Code.Leaflet does not create a JavaScript LeafletMap class, so technically it's more a LeafletUtils than a LeafletMap, isn't it? I acknowledge I'm picky with names... I noticed that leaflet-main requires leaflet-commons but I'm actually wondering how to make sure that leaflet-commons is known from RequireJS before leaflet-main gets loaded. I have not faced any error in practice, but I'm wondering if you tackled the issue already or if we need to figure it out.

>     Ludovic just suggested an improvement (for the next versions): let the user configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used.
>
>
> Thanks Ludovic for your suggestion. I would look into the calendar application to have a better understanding of this and let you know my thoughts.

Ok cool.

Cheers

Stéphane


> Best,
> Fawad
>
>
> On Wed, Jul 10, 2019 at 2:55 PM Stéphane Laurière <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi Fawad,
>
>     Good to hear from you again, I hope things are fine on your end as well. Thanks for the update. Sorry for the delay, we were traveling yesterday. Releasing the application soon sounds good. I'm facing a few issues though, they may be related to an installation issue on my side, not sure. I grabbed the latest code and imported as a XAR over the existing pages in my 11.x wiki without error, and I notice the following (I'll consider posting some Jira issues if needed):
>
>     - catalina.out errors (not sure if they were present with previous version):
>
>     2019-07-10 11:34:30,349 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Error at line 203, column 85: missing variable name. Caused by: [      var index = 0, lat = 0, lng = 0, coordinates = [], shift = 0, result = 0, byte = null, latitude_change, longitude_change, factor = Math.pow(10, Number.isInteger(precision) ? precision : 5);]
>     2019-07-10 11:34:30,350 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Error at line 206, column 13: identifier is a reserved word. Caused [...]
>     2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] ERROR c.x.x.w.s.JsExtension          - Runtime error minimizing JSX object: Compilation produced 8 syntax errors.
>     2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Failed to compress JS extension: null
>
>     - On the UI side, possibly as a consequence, I can't see a list of results anymore, and the search widget state is not restored.
>
>     - I notice there is no default radio button checked in the search form: I think either "location" or "item" should be checked, to let the user know what's the default (I'd say "item").
>
>     - I think the name "Maps.Code.Leaflet" might be misleading for potential developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think?
>
>     - Ludovic just suggested an improvement (for the next versions): let the user configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used.
>
>     Cheers
>
>     Stéphane
>
>
>     Fawad Ali:
>      > Hi all,
>      > Hope everyone is well.
>      >
>      > Please review the application developed so far. I have included a UI test and map states. I think we should release the application as soon as we can so that user reviews can be gathered.
>      >
>      > Best,
>      > Fawad
>


--
Stéphane Laurière
XWiki – https://xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi all,

However, as a user I would expect the list to be present also when the
> search input is empty, with the possibility to reduce the list by hitting
> the link "Show result items", what do you think?


By this do you mean that all the results should show in the "Show result
items" when the search is empty? Thereby decreasing the number of result
items when an actual search is made.

Speaking of the list, that'd be great imho that the popups can be displayed
> while the list is active, so that the user can browse content via the list,
> wouldn't it?
>

I am not too sure where we could place them, since both the list and popups
take a large amount of space. The popups are build to support page data, so
they are also big. We could do it so the upper space belongs to the popup
and the lower space belongs to the list. Though it will cramp the space a
little imo. We could also increase the overall height of the map (which is
400px for now). WDYT?

 Restoring the full screen is working in most cases, that's cool, however
> if I run a search, then enter full screen, then refine the search, it seems
> that the full screen state is not preserved, is it?
>

That's one use case which leads to a loss of the previous map state and the
one before that is used. Any state before the facet click is not preserved
except the search widget and "Refine your search" area which is more or
less forced. As I said before, the problem is that we cannot pass the state
anywhere when a facet is clicked. I will look into cumulative onclick
events but I think that's not going to work.

I agree LeafletMap would be closer to what it does, but contrarily to the
> Macro Map, if I'm not mistaken, the page currently named Maps.Code.Leaflet
> does not create a JavaScript LeafletMap class, so technically it's more a
> LeafletUtils than a LeafletMap, isn't it?
>

You are right, it does not create any js class and since css is also inside
the same page the name should be LeafletUtils or LeafletService. I will
change it accordingly.

Also, I looked into it and the idea of custom class property for getting
the location is interesting indeed. I will see how I should prioritize it
and implement it then since we have other major features to look into.

I would also like to ask; what do you foresee as the basic elements of the
application? We have map configuration, map query, search and filter
widget, markers and popups so far. Do you have anything other than this in
mind that could be thought of as the basis of the application? I think we
should completely stabilize the basics by the end of this week so I can
work on other features like map paths, indoor maps and custom shapes.

Best,
Fawad

On Thu, Jul 11, 2019 at 1:50 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad, all,
>
> > I have fixed the errors you mentioned. It appears one of the variables
> had a bad name which was causing the error.
> The error does not show anymore indeed on my end, thanks.
>
> >     On the UI side, possibly as a consequence, I can't see a list of
> results anymore, and the search widget state is not restored.
> >
> >
> > The list of results is just fine on my end, I am not sure what could be
> wrong.
>
> In the meantime, I figured out that the list shows up indeed when issuing
> a query in the search input, cool. However, as a user I would expect the
> list to be present also when the search input is empty, with the
> possibility to reduce the list by hitting the link "Show result items",
> what do you think? Speaking of the list, that'd be great imho that the
> popups can be displayed while the list is active, so that the user can
> browse content via the list, wouldn't it? This should not prevent us from
> release version 1.0 though.
>
> > About the map state, it does not work well with facets. Since facets
> have a separate code we cannot apply custom code when a facet is selected
> thus limiting our ability to pass the map state through js. I tried looking
> around for related js events but could not find one through which we can
> pass the map state after a facet is clicked. Do you have anything in mind
> for this?
>
> Actually, with the new version, the facet state is restored as I would
> expect it, sorry for the confusion. Restoring the full screen is working in
> most cases, that's cool, however if I run a search, then enter full screen,
> then refine the search, it seems that the full screen state is not
> preserved, is it?
>
> A note about demos: as far as I can see, the museum map demo does not
> showcase the "country" facet by default, don't you think that'd be worth
> adding it so that the user has a simple demo with facets working with
> custom fields?
>
> >     I think the name "Maps.Code.Leaflet" might be misleading for
> potential developers: this could mean this page is providing Leaflet, while
> it does not. I would suggest to choose a name that is closer to what the
> JavaScript really provides, from a functional point of view, what do you
> think?
> >
> >
> > I think its fine as is. Since it is placed inside the Code space, the
> developers will immediately be able to know that all the Leaflet related
> code resides inside it. But to be on the safe side, we can rename it to
> LeafletMap as in the macro-map.
>
> I agree LeafletMap would be closer to what it does, but contrarily to the
> Macro Map, if I'm not mistaken, the page currently named Maps.Code.Leaflet
> does not create a JavaScript LeafletMap class, so technically it's more a
> LeafletUtils than a LeafletMap, isn't it? I acknowledge I'm picky with
> names... I noticed that leaflet-main requires leaflet-commons but I'm
> actually wondering how to make sure that leaflet-commons is known from
> RequireJS before leaflet-main gets loaded. I have not faced any error in
> practice, but I'm wondering if you tackled the issue already or if we need
> to figure it out.
>
> >     Ludovic just suggested an improvement (for the next versions): let
> the user configure which existing field could be used in an existing class
> for retrieving geographical information, that could be interesting indeed,
> to be discussed. The calendar application works this way already as far as
> I understood: it lets the user define the date / time field to be used.
> >
> >
> > Thanks Ludovic for your suggestion. I would look into the calendar
> application to have a better understanding of this and let you know my
> thoughts.
>
> Ok cool.
>
> Cheers
>
> Stéphane
>
>
> > Best,
> > Fawad
> >
> >
> > On Wed, Jul 10, 2019 at 2:55 PM Stéphane Laurière <[hidden email]
> <mailto:[hidden email]>> wrote:
> >
> >     Hi Fawad,
> >
> >     Good to hear from you again, I hope things are fine on your end as
> well. Thanks for the update. Sorry for the delay, we were traveling
> yesterday. Releasing the application soon sounds good. I'm facing a few
> issues though, they may be related to an installation issue on my side, not
> sure. I grabbed the latest code and imported as a XAR over the existing
> pages in my 11.x wiki without error, and I notice the following (I'll
> consider posting some Jira issues if needed):
> >
> >     - catalina.out errors (not sure if they were present with previous
> version):
> >
> >     2019-07-10 11:34:30,349 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Error at line 203, column 85:
> missing variable name. Caused by: [      var index = 0, lat = 0, lng = 0,
> coordinates = [], shift = 0, result = 0, byte = null, latitude_change,
> longitude_change, factor = Math.pow(10, Number.isInteger(precision) ?
> precision : 5);]
> >     2019-07-10 11:34:30,350 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Error at line 206, column 13:
> identifier is a reserved word. Caused [...]
> >     2019-07-10 11:35:02,841 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> ERROR c.x.x.w.s.JsExtension          - Runtime error minimizing JSX object:
> Compilation produced 8 syntax errors.
> >     2019-07-10 11:35:02,841 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Failed to compress JS extension: null
> >
> >     - On the UI side, possibly as a consequence, I can't see a list of
> results anymore, and the search widget state is not restored.
> >
> >     - I notice there is no default radio button checked in the search
> form: I think either "location" or "item" should be checked, to let the
> user know what's the default (I'd say "item").
> >
> >     - I think the name "Maps.Code.Leaflet" might be misleading for
> potential developers: this could mean this page is providing Leaflet, while
> it does not. I would suggest to choose a name that is closer to what the
> JavaScript really provides, from a functional point of view, what do you
> think?
> >
> >     - Ludovic just suggested an improvement (for the next versions): let
> the user configure which existing field could be used in an existing class
> for retrieving geographical information, that could be interesting indeed,
> to be discussed. The calendar application works this way already as far as
> I understood: it lets the user define the date / time field to be used.
> >
> >     Cheers
> >
> >     Stéphane
> >
> >
> >     Fawad Ali:
> >      > Hi all,
> >      > Hope everyone is well.
> >      >
> >      > Please review the application developed so far. I have included a
> UI test and map states. I think we should release the application as soon
> as we can so that user reviews can be gathered.
> >      >
> >      > Best,
> >      > Fawad
> >
>
>
> --
> Stéphane Laurière
> XWiki – https://xwiki.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
Hi Fawad, Hi all,

> Hi all,
>
>     However, as a user I would expect the list to be present also when the search input is empty, with the possibility to reduce the list by hitting the link "Show result items", what do you think?
>
>
> By this do you mean that all the results should show in the "Show result items" when the search is empty? Thereby decreasing the number of result items when an actual search is made.

Yes indeed, the number of items would then decrease either when a text search is made or a facet filter is checked.

>     Speaking of the list, that'd be great imho that the popups can be displayed while the list is active, so that the user can browse content via the list, wouldn't it?
>
>
> I am not too sure where we could place them, since both the list and popups take a large amount of space. The popups are build to support page data, so they are also big. We could do it so the upper space belongs to the popup and the lower space belongs to the list. Though it will cramp the space a little imo. We could also increase the overall height of the map (which is 400px for now). WDYT?

As a user, I like the Airbnb map experience with popups on top of the markers, what about you?

<https://www.airbnb.com/s/soweto/homes?refinement_paths%5B%5D=%2Fhomes&query=soweto&click_referer=t%3ASEE_ALL%7Csid%3A8a34e891-60f3-47cd-a4e6-bb4182ff26ac%7Cst%3AMAGAZINE_HOMES&search_type=unknown&zoom=11&search_by_map=true&sw_lat=-26.439251721636115&sw_lng=27.49917114990228&ne_lat=-25.91485138495341&ne_lng=28.197489631347594&checkin=2019-07-18&checkout=2019-07-20&place_id=ChIJcWB04rGmlR4R322eHsI4CDo&s_tag=t8HDGbAs>

The ability to highlight a marker when hovering the list is also quite handy.

(note also the "search as I move the map feature")

Imho the popups could be reasonably small by default, and later on we may consider various improvements such as 1) the ability to increase the popup side dynamically like what happens on the map below when you hit the link "Plus d'information" at the bottom of the panel: http://carte.preference-commerce.fr/cci-fr/ 2) the ability to choose where this contextual information should show up. For instance, for users having large content to get displayed, it could make sense to let the content replace entirely the list one, just like what Google does in this example (which is close to what we have at the moment, except that I wouldn't hide the search input, and I would add a "Back to results" link just like what Google does, and keep the same container so that the user understands better that the two panels are complementary, I find it easier to grasp the underlying behaviour):

<https://www.google.com/maps/place/Ch%C3%A2teau+De+Monteton/@44.6171828,0.1365399,11z/data=!4m11!1m2!2m1!1srestaurant!3m7!1s0x12aa94fd12973be1:0x5c1dfe53cb53965f!5m2!4m1!1i2!8m2!3d44.6227756!4d0.2553132>

Along this line, another improvement (you probably have it in mind) would be to introduce one or several dedicated sheets for such contextual information so that it can get easily customized by users with development skills.

>       Restoring the full screen is working in most cases, that's cool, however if I run a search, then enter full screen, then refine the search, it seems that the full screen state is not preserved, is it?
>
>
> That's one use case which leads to a loss of the previous map state and the one before that is used. Any state before the facet click is not preserved except the search widget and "Refine your search" area which is more or less forced. As I said before, the problem is that we cannot pass the state anywhere when a facet is clicked. I will look into cumulative onclick events but I think that's not going to work.

Ok, we need to investigate this. I have a preliminary question about this feature: how come that the URL does not reflect the mode status when hitting the full screen button the first time? I mean, if I'm not mistaken, when hitting the button before running any search, the URL remains unchanged, while the user may want to use that URL to share the map in full screen as is, or to embed it in full screen in a iframe, so shouldn't this parameter be present? Is there any difficulty with that? Wouldn't the facet widget reuse that URL afterwards? Sorry for any possible misunderstanding on my end.


>     I agree LeafletMap would be closer to what it does, but contrarily to the Macro Map, if I'm not mistaken, the page currently named Maps.Code.Leaflet does not create a JavaScript LeafletMap class, so technically it's more a LeafletUtils than a LeafletMap, isn't it?
>
>
> You are right, it does not create any js class and since css is also inside the same page the name should be LeafletUtils or LeafletService. I will change it accordingly.

Ok cool.

> Also, I looked into it and the idea of custom class property for getting the location is interesting indeed. I will see how I should prioritize it and implement it then since we have other major features to look into.
>
> I would also like to ask; what do you foresee as the basic elements of the application? We have map configuration, map query, search and filter widget, markers and popups so far. Do you have anything other than this in mind that could be thought of as the basis of the application? I think we should completely stabilize the basics by the end of this week so I can work on other features like map paths, indoor maps and custom shapes.

I'll think about it and will give you my feedback on this as soon as possible.

Cheers

Stéphane

 

> Best,
> Fawad
>
> On Thu, Jul 11, 2019 at 1:50 PM Stéphane Laurière <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hi Fawad, all,
>
>      > I have fixed the errors you mentioned. It appears one of the variables had a bad name which was causing the error.
>     The error does not show anymore indeed on my end, thanks.
>
>      >     On the UI side, possibly as a consequence, I can't see a list of results anymore, and the search widget state is not restored.
>      >
>      >
>      > The list of results is just fine on my end, I am not sure what could be wrong.
>
>     In the meantime, I figured out that the list shows up indeed when issuing a query in the search input, cool. However, as a user I would expect the list to be present also when the search input is empty, with the possibility to reduce the list by hitting the link "Show result items", what do you think? Speaking of the list, that'd be great imho that the popups can be displayed while the list is active, so that the user can browse content via the list, wouldn't it? This should not prevent us from release version 1.0 though.
>
>      > About the map state, it does not work well with facets. Since facets have a separate code we cannot apply custom code when a facet is selected thus limiting our ability to pass the map state through js. I tried looking around for related js events but could not find one through which we can pass the map state after a facet is clicked. Do you have anything in mind for this?
>
>     Actually, with the new version, the facet state is restored as I would expect it, sorry for the confusion. Restoring the full screen is working in most cases, that's cool, however if I run a search, then enter full screen, then refine the search, it seems that the full screen state is not preserved, is it?
>
>     A note about demos: as far as I can see, the museum map demo does not showcase the "country" facet by default, don't you think that'd be worth adding it so that the user has a simple demo with facets working with custom fields?
>
>      >     I think the name "Maps.Code.Leaflet" might be misleading for potential developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think?
>      >
>      >
>      > I think its fine as is. Since it is placed inside the Code space, the developers will immediately be able to know that all the Leaflet related code resides inside it. But to be on the safe side, we can rename it to LeafletMap as in the macro-map.
>
>     I agree LeafletMap would be closer to what it does, but contrarily to the Macro Map, if I'm not mistaken, the page currently named Maps.Code.Leaflet does not create a JavaScript LeafletMap class, so technically it's more a LeafletUtils than a LeafletMap, isn't it? I acknowledge I'm picky with names... I noticed that leaflet-main requires leaflet-commons but I'm actually wondering how to make sure that leaflet-commons is known from RequireJS before leaflet-main gets loaded. I have not faced any error in practice, but I'm wondering if you tackled the issue already or if we need to figure it out.
>
>      >     Ludovic just suggested an improvement (for the next versions): let the user configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used.
>      >
>      >
>      > Thanks Ludovic for your suggestion. I would look into the calendar application to have a better understanding of this and let you know my thoughts.
>
>     Ok cool.
>
>     Cheers
>
>     Stéphane
>
>
>      > Best,
>      > Fawad
>      >
>      >
>      > On Wed, Jul 10, 2019 at 2:55 PM Stéphane Laurière <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>      >
>      >     Hi Fawad,
>      >
>      >     Good to hear from you again, I hope things are fine on your end as well. Thanks for the update. Sorry for the delay, we were traveling yesterday. Releasing the application soon sounds good. I'm facing a few issues though, they may be related to an installation issue on my side, not sure. I grabbed the latest code and imported as a XAR over the existing pages in my 11.x wiki without error, and I notice the following (I'll consider posting some Jira issues if needed):
>      >
>      >     - catalina.out errors (not sure if they were present with previous version):
>      >
>      >     2019-07-10 11:34:30,349 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Error at line 203, column 85: missing variable name. Caused by: [      var index = 0, lat = 0, lng = 0, coordinates = [], shift = 0, result = 0, byte = null, latitude_change, longitude_change, factor = Math.pow(10, Number.isInteger(precision) ? precision : 5);]
>      >     2019-07-10 11:34:30,350 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Error at line 206, column 13: identifier is a reserved word. Caused [...]
>      >     2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] ERROR c.x.x.w.s.JsExtension          - Runtime error minimizing JSX object: Compilation produced 8 syntax errors.
>      >     2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN  c.x.x.w.s.JsExtension          - Failed to compress JS extension: null
>      >
>      >     - On the UI side, possibly as a consequence, I can't see a list of results anymore, and the search widget state is not restored.
>      >
>      >     - I notice there is no default radio button checked in the search form: I think either "location" or "item" should be checked, to let the user know what's the default (I'd say "item").
>      >
>      >     - I think the name "Maps.Code.Leaflet" might be misleading for potential developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think?
>      >
>      >     - Ludovic just suggested an improvement (for the next versions): let the user configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used.
>      >
>      >     Cheers
>      >
>      >     Stéphane
>      >
>      >
>      >     Fawad Ali:
>      >      > Hi all,
>      >      > Hope everyone is well.
>      >      >
>      >      > Please review the application developed so far. I have included a UI test and map states. I think we should release the application as soon as we can so that user reviews can be gathered.
>      >      >
>      >      > Best,
>      >      > Fawad
>      >
>
>
>     --
>     Stéphane Laurière
>     XWiki – https://xwiki.com
>


--
Stéphane Laurière
XWiki – https://xwiki.com

Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
>
> As a user, I like the Airbnb map experience with popups on top of the
> markers, what about you?


That is much like the default view of popups in Leaflet. This kind of popup
supports very little information, that's why I made a dedicated space for
popups. However, we could go with your suggestion of "view more". We could
either open the parent page with "view more" or fill the search widget as
you suggested. I would go with displaying more information in the search
widget. Is that fine with you?

Along this line, another improvement (you probably have it in mind) would
> be to introduce one or several dedicated sheets for such contextual
> information so that it can get easily customized by users with development
> skills.
>

I do not think this is required. If a developer wants a custom display for
the popup information, he can create a class sheet and make pages with that
sheet and it will become a map item after adding location object to the
page.

Ok, we need to investigate this. I have a preliminary question about this
> feature: how come that the URL does not reflect the mode status when
> hitting the full screen button the first time? I mean, if I'm not mistaken,
> when hitting the button before running any search, the URL remains
> unchanged, while the user may want to use that URL to share the map in full
> screen as is, or to embed it in full screen in a iframe, so shouldn't this
> parameter be present? Is there any difficulty with that? Wouldn't the facet
> widget reuse that URL afterwards? Sorry for any possible misunderstanding
> on my end.
>

I did not go with this flow because of better performance since a separate
async request will be made for change in each state. What I am doing now is
that I take the map state on search or other events that reload the map
asynchronously.Thanks for your suggestion Stephane. I could update the page
by observing a change in each state. This is a little slow because the map
will have to be reloaded for each state but still a good option.

Best,
Fawad


On Thu, Jul 11, 2019 at 3:26 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad, Hi all,
>
> > Hi all,
> >
> >     However, as a user I would expect the list to be present also when
> the search input is empty, with the possibility to reduce the list by
> hitting the link "Show result items", what do you think?
> >
> >
> > By this do you mean that all the results should show in the "Show result
> items" when the search is empty? Thereby decreasing the number of result
> items when an actual search is made.
>
> Yes indeed, the number of items would then decrease either when a text
> search is made or a facet filter is checked.
>
> >     Speaking of the list, that'd be great imho that the popups can be
> displayed while the list is active, so that the user can browse content via
> the list, wouldn't it?
> >
> >
> > I am not too sure where we could place them, since both the list and
> popups take a large amount of space. The popups are build to support page
> data, so they are also big. We could do it so the upper space belongs to
> the popup and the lower space belongs to the list. Though it will cramp the
> space a little imo. We could also increase the overall height of the map
> (which is 400px for now). WDYT?
>
> As a user, I like the Airbnb map experience with popups on top of the
> markers, what about you?
>
> <
> https://www.airbnb.com/s/soweto/homes?refinement_paths%5B%5D=%2Fhomes&query=soweto&click_referer=t%3ASEE_ALL%7Csid%3A8a34e891-60f3-47cd-a4e6-bb4182ff26ac%7Cst%3AMAGAZINE_HOMES&search_type=unknown&zoom=11&search_by_map=true&sw_lat=-26.439251721636115&sw_lng=27.49917114990228&ne_lat=-25.91485138495341&ne_lng=28.197489631347594&checkin=2019-07-18&checkout=2019-07-20&place_id=ChIJcWB04rGmlR4R322eHsI4CDo&s_tag=t8HDGbAs
> >
>
> The ability to highlight a marker when hovering the list is also quite
> handy.
>
> (note also the "search as I move the map feature")
>
> Imho the popups could be reasonably small by default, and later on we may
> consider various improvements such as 1) the ability to increase the popup
> side dynamically like what happens on the map below when you hit the link
> "Plus d'information" at the bottom of the panel:
> http://carte.preference-commerce.fr/cci-fr/ 2) the ability to choose
> where this contextual information should show up. For instance, for users
> having large content to get displayed, it could make sense to let the
> content replace entirely the list one, just like what Google does in this
> example (which is close to what we have at the moment, except that I
> wouldn't hide the search input, and I would add a "Back to results" link
> just like what Google does, and keep the same container so that the user
> understands better that the two panels are complementary, I find it easier
> to grasp the underlying behaviour):
>
> <
> https://www.google.com/maps/place/Ch%C3%A2teau+De+Monteton/@44.6171828,0.1365399,11z/data=!4m11!1m2!2m1!1srestaurant!3m7!1s0x12aa94fd12973be1:0x5c1dfe53cb53965f!5m2!4m1!1i2!8m2!3d44.6227756!4d0.2553132
> >
>
> Along this line, another improvement (you probably have it in mind) would
> be to introduce one or several dedicated sheets for such contextual
> information so that it can get easily customized by users with development
> skills.
>
> >       Restoring the full screen is working in most cases, that's cool,
> however if I run a search, then enter full screen, then refine the search,
> it seems that the full screen state is not preserved, is it?
> >
> >
> > That's one use case which leads to a loss of the previous map state and
> the one before that is used. Any state before the facet click is not
> preserved except the search widget and "Refine your search" area which is
> more or less forced. As I said before, the problem is that we cannot pass
> the state anywhere when a facet is clicked. I will look into cumulative
> onclick events but I think that's not going to work.
>
> Ok, we need to investigate this. I have a preliminary question about this
> feature: how come that the URL does not reflect the mode status when
> hitting the full screen button the first time? I mean, if I'm not mistaken,
> when hitting the button before running any search, the URL remains
> unchanged, while the user may want to use that URL to share the map in full
> screen as is, or to embed it in full screen in a iframe, so shouldn't this
> parameter be present? Is there any difficulty with that? Wouldn't the facet
> widget reuse that URL afterwards? Sorry for any possible misunderstanding
> on my end.
>
>
> >     I agree LeafletMap would be closer to what it does, but contrarily
> to the Macro Map, if I'm not mistaken, the page currently named
> Maps.Code.Leaflet does not create a JavaScript LeafletMap class, so
> technically it's more a LeafletUtils than a LeafletMap, isn't it?
> >
> >
> > You are right, it does not create any js class and since css is also
> inside the same page the name should be LeafletUtils or LeafletService. I
> will change it accordingly.
>
> Ok cool.
>
> > Also, I looked into it and the idea of custom class property for getting
> the location is interesting indeed. I will see how I should prioritize it
> and implement it then since we have other major features to look into.
> >
> > I would also like to ask; what do you foresee as the basic elements of
> the application? We have map configuration, map query, search and filter
> widget, markers and popups so far. Do you have anything other than this in
> mind that could be thought of as the basis of the application? I think we
> should completely stabilize the basics by the end of this week so I can
> work on other features like map paths, indoor maps and custom shapes.
>
> I'll think about it and will give you my feedback on this as soon as
> possible.
>
> Cheers
>
> Stéphane
>
>
> > Best,
> > Fawad
> >
> > On Thu, Jul 11, 2019 at 1:50 PM Stéphane Laurière <[hidden email]
> <mailto:[hidden email]>> wrote:
> >
> >     Hi Fawad, all,
> >
> >      > I have fixed the errors you mentioned. It appears one of the
> variables had a bad name which was causing the error.
> >     The error does not show anymore indeed on my end, thanks.
> >
> >      >     On the UI side, possibly as a consequence, I can't see a list
> of results anymore, and the search widget state is not restored.
> >      >
> >      >
> >      > The list of results is just fine on my end, I am not sure what
> could be wrong.
> >
> >     In the meantime, I figured out that the list shows up indeed when
> issuing a query in the search input, cool. However, as a user I would
> expect the list to be present also when the search input is empty, with the
> possibility to reduce the list by hitting the link "Show result items",
> what do you think? Speaking of the list, that'd be great imho that the
> popups can be displayed while the list is active, so that the user can
> browse content via the list, wouldn't it? This should not prevent us from
> release version 1.0 though.
> >
> >      > About the map state, it does not work well with facets. Since
> facets have a separate code we cannot apply custom code when a facet is
> selected thus limiting our ability to pass the map state through js. I
> tried looking around for related js events but could not find one through
> which we can pass the map state after a facet is clicked. Do you have
> anything in mind for this?
> >
> >     Actually, with the new version, the facet state is restored as I
> would expect it, sorry for the confusion. Restoring the full screen is
> working in most cases, that's cool, however if I run a search, then enter
> full screen, then refine the search, it seems that the full screen state is
> not preserved, is it?
> >
> >     A note about demos: as far as I can see, the museum map demo does
> not showcase the "country" facet by default, don't you think that'd be
> worth adding it so that the user has a simple demo with facets working with
> custom fields?
> >
> >      >     I think the name "Maps.Code.Leaflet" might be misleading for
> potential developers: this could mean this page is providing Leaflet, while
> it does not. I would suggest to choose a name that is closer to what the
> JavaScript really provides, from a functional point of view, what do you
> think?
> >      >
> >      >
> >      > I think its fine as is. Since it is placed inside the Code space,
> the developers will immediately be able to know that all the Leaflet
> related code resides inside it. But to be on the safe side, we can rename
> it to LeafletMap as in the macro-map.
> >
> >     I agree LeafletMap would be closer to what it does, but contrarily
> to the Macro Map, if I'm not mistaken, the page currently named
> Maps.Code.Leaflet does not create a JavaScript LeafletMap class, so
> technically it's more a LeafletUtils than a LeafletMap, isn't it? I
> acknowledge I'm picky with names... I noticed that leaflet-main requires
> leaflet-commons but I'm actually wondering how to make sure that
> leaflet-commons is known from RequireJS before leaflet-main gets loaded. I
> have not faced any error in practice, but I'm wondering if you tackled the
> issue already or if we need to figure it out.
> >
> >      >     Ludovic just suggested an improvement (for the next
> versions): let the user configure which existing field could be used in an
> existing class for retrieving geographical information, that could be
> interesting indeed, to be discussed. The calendar application works this
> way already as far as I understood: it lets the user define the date / time
> field to be used.
> >      >
> >      >
> >      > Thanks Ludovic for your suggestion. I would look into the
> calendar application to have a better understanding of this and let you
> know my thoughts.
> >
> >     Ok cool.
> >
> >     Cheers
> >
> >     Stéphane
> >
> >
> >      > Best,
> >      > Fawad
> >      >
> >      >
> >      > On Wed, Jul 10, 2019 at 2:55 PM Stéphane Laurière <
> [hidden email] <mailto:[hidden email]> <mailto:
> [hidden email] <mailto:[hidden email]>>> wrote:
> >      >
> >      >     Hi Fawad,
> >      >
> >      >     Good to hear from you again, I hope things are fine on your
> end as well. Thanks for the update. Sorry for the delay, we were traveling
> yesterday. Releasing the application soon sounds good. I'm facing a few
> issues though, they may be related to an installation issue on my side, not
> sure. I grabbed the latest code and imported as a XAR over the existing
> pages in my 11.x wiki without error, and I notice the following (I'll
> consider posting some Jira issues if needed):
> >      >
> >      >     - catalina.out errors (not sure if they were present with
> previous version):
> >      >
> >      >     2019-07-10 11:34:30,349 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Error at line 203, column 85:
> missing variable name. Caused by: [      var index = 0, lat = 0, lng = 0,
> coordinates = [], shift = 0, result = 0, byte = null, latitude_change,
> longitude_change, factor = Math.pow(10, Number.isInteger(precision) ?
> precision : 5);]
> >      >     2019-07-10 11:34:30,350 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Error at line 206, column 13:
> identifier is a reserved word. Caused [...]
> >      >     2019-07-10 11:35:02,841 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> ERROR c.x.x.w.s.JsExtension          - Runtime error minimizing JSX object:
> Compilation produced 8 syntax errors.
> >      >     2019-07-10 11:35:02,841 [
> http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1]
> WARN  c.x.x.w.s.JsExtension          - Failed to compress JS extension: null
> >      >
> >      >     - On the UI side, possibly as a consequence, I can't see a
> list of results anymore, and the search widget state is not restored.
> >      >
> >      >     - I notice there is no default radio button checked in the
> search form: I think either "location" or "item" should be checked, to let
> the user know what's the default (I'd say "item").
> >      >
> >      >     - I think the name "Maps.Code.Leaflet" might be misleading
> for potential developers: this could mean this page is providing Leaflet,
> while it does not. I would suggest to choose a name that is closer to what
> the JavaScript really provides, from a functional point of view, what do
> you think?
> >      >
> >      >     - Ludovic just suggested an improvement (for the next
> versions): let the user configure which existing field could be used in an
> existing class for retrieving geographical information, that could be
> interesting indeed, to be discussed. The calendar application works this
> way already as far as I understood: it lets the user define the date / time
> field to be used.
> >      >
> >      >     Cheers
> >      >
> >      >     Stéphane
> >      >
> >      >
> >      >     Fawad Ali:
> >      >      > Hi all,
> >      >      > Hope everyone is well.
> >      >      >
> >      >      > Please review the application developed so far. I have
> included a UI test and map states. I think we should release the
> application as soon as we can so that user reviews can be gathered.
> >      >      >
> >      >      > Best,
> >      >      > Fawad
> >      >
> >
> >
> >     --
> >     Stéphane Laurière
> >     XWiki – https://xwiki.com
> >
>
>
> --
> Stéphane Laurière
> XWiki – https://xwiki.com
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6

Fawad,

>     As a user, I like the Airbnb map experience with popups on top of the markers, what about you?
>
>
> That is much like the default view of popups in Leaflet. This kind of popup supports very little information, that's why I made a dedicated space for popups. However, we could go with your suggestion of "view more". We could either open the parent page with "view more" or fill the search widget as you suggested. I would go with displaying more information in the search widget. Is that fine with you?

I would say that typical users will want to choose between displaying information in a popup or over the search results panel, depending on the user experience they prefer and the amount of information they want to display. Typically, Google Maps and the Airbnb map have two different approaches with this respect, and it would be a plus imho to implement the two. Airbnb maps display popups, they are small indeed, but the image slider lets the user obtain a significant amount of information. For displaying more information like hotel schedule, ratings, comments, it's clear that a bigger panel is useful, like what Google Maps is proposing.

I would go for small popups to start with (version 1.0), with a link to the underlying XWiki page indeed. Later on, if time permits depending on the priorities we decide, we could implement 1) a dynamic "more information widget" that enlarges the popup dynamically, 2) a different interaction mechanism that is similar to the Google Maps one. Let's add these features as issues in Jira and refine the roadmap while defining the upcoming versions, what do you think?

>     Along this line, another improvement (you probably have it in mind) would be to introduce one or several dedicated sheets for such contextual information so that it can get easily customized by users with development skills.
>
>
> I do not think this is required. If a developer wants a custom display for the popup information, he can create a class sheet and make pages with that sheet and it will become a map item after adding location object to the page.

It will become a map item indeed, however, let's look closer at what Airbnb is proposing: they typically manage three sheets:

- One for the item page when displayed individually, for example: https://up1.xwikisas.com/#0EcYpY5TQvlCAKuWP3AYIw
- One for displaying the item in a list: https://up1.xwikisas.com/#yYiN8KfeKuy1BqibkgSkAA
- One for displaying the same item in a popup: same link, right side

A customized class sheet would typically get used for the first display as you envision it, but for the two others, which would be useful for advanced maps imho, I was considering we could implement a built-in mechanism allowing easy customization.

>     Ok, we need to investigate this. I have a preliminary question about this feature: how come that the URL does not reflect the mode status when hitting the full screen button the first time? I mean, if I'm not mistaken, when hitting the button before running any search, the URL remains unchanged, while the user may want to use that URL to share the map in full screen as is, or to embed it in full screen in a iframe, so shouldn't this parameter be present? Is there any difficulty with that? Wouldn't the facet widget reuse that URL afterwards? Sorry for any possible misunderstanding on my end.
>
>
> I did not go with this flow because of better performance since a separate async request will be made for change in each state. What I am doing now is that I take the map state on search or other events that reload the map asynchronously.Thanks for your suggestion Stephane. I could update the page by observing a change in each state. This is a little slow because the map will have to be reloaded for each state but still a good option.

Ok great, looking forward to testing the new version

Cheers

Stéphane



Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi all,

I would go for small popups to start with (version 1.0), with a link to the
> underlying XWiki page indeed. Later on, if time permits depending on the
> priorities we decide, we could implement 1) a dynamic "more information
> widget" that enlarges the popup dynamically, 2) a different interaction
> mechanism that is similar to the Google Maps one. Let's add these features
> as issues in Jira and refine the roadmap while defining the upcoming
> versions, what do you think?
>

Stephane, as you suggest, let's go with smaller popups for now then. We can
decide other placements later on if any.

It will become a map item indeed, however, let's look closer at what Airbnb

> is proposing: they typically manage three sheets:
>
> - One for the item page when displayed individually, for example:
> https://up1.xwikisas.com/#0EcYpY5TQvlCAKuWP3AYIw
> - One for displaying the item in a list:
> https://up1.xwikisas.com/#yYiN8KfeKuy1BqibkgSkAA
> - One for displaying the same item in a popup: same link, right side
>
> A customized class sheet would typically get used for the first display as
> you envision it, but for the two others, which would be useful for advanced
> maps imho, I was considering we could implement a built-in mechanism
> allowing easy customization.
>

We could make it so that custom sheets can be used for displaying items in
the popup. That way the user can create any sheet of his choice and use
that. I will look into how this would be implemented.

For now I am working on the issues you created so far. I will let you know
how we could move forward from there.

Thanks for your detailed suggestions, Stephane. It really helps in
directing the application the right way. :)

Best,
Fawad


On Thu, Jul 11, 2019 at 6:10 PM Stéphane Laurière <[hidden email]>
wrote:

>
> Fawad,
>
> >     As a user, I like the Airbnb map experience with popups on top of
> the markers, what about you?
> >
> >
> > That is much like the default view of popups in Leaflet. This kind of
> popup supports very little information, that's why I made a dedicated space
> for popups. However, we could go with your suggestion of "view more". We
> could either open the parent page with "view more" or fill the search
> widget as you suggested. I would go with displaying more information in the
> search widget. Is that fine with you?
>
> I would say that typical users will want to choose between displaying
> information in a popup or over the search results panel, depending on the
> user experience they prefer and the amount of information they want to
> display. Typically, Google Maps and the Airbnb map have two different
> approaches with this respect, and it would be a plus imho to implement the
> two. Airbnb maps display popups, they are small indeed, but the image
> slider lets the user obtain a significant amount of information. For
> displaying more information like hotel schedule, ratings, comments, it's
> clear that a bigger panel is useful, like what Google Maps is proposing.
>
> I would go for small popups to start with (version 1.0), with a link to
> the underlying XWiki page indeed. Later on, if time permits depending on
> the priorities we decide, we could implement 1) a dynamic "more information
> widget" that enlarges the popup dynamically, 2) a different interaction
> mechanism that is similar to the Google Maps one. Let's add these features
> as issues in Jira and refine the roadmap while defining the upcoming
> versions, what do you think?
>
> >     Along this line, another improvement (you probably have it in mind)
> would be to introduce one or several dedicated sheets for such contextual
> information so that it can get easily customized by users with development
> skills.
> >
> >
> > I do not think this is required. If a developer wants a custom display
> for the popup information, he can create a class sheet and make pages with
> that sheet and it will become a map item after adding location object to
> the page.
>
> It will become a map item indeed, however, let's look closer at what
> Airbnb is proposing: they typically manage three sheets:
>
> - One for the item page when displayed individually, for example:
> https://up1.xwikisas.com/#0EcYpY5TQvlCAKuWP3AYIw
> - One for displaying the item in a list:
> https://up1.xwikisas.com/#yYiN8KfeKuy1BqibkgSkAA
> - One for displaying the same item in a popup: same link, right side
>
> A customized class sheet would typically get used for the first display as
> you envision it, but for the two others, which would be useful for advanced
> maps imho, I was considering we could implement a built-in mechanism
> allowing easy customization.
>
> >     Ok, we need to investigate this. I have a preliminary question about
> this feature: how come that the URL does not reflect the mode status when
> hitting the full screen button the first time? I mean, if I'm not mistaken,
> when hitting the button before running any search, the URL remains
> unchanged, while the user may want to use that URL to share the map in full
> screen as is, or to embed it in full screen in a iframe, so shouldn't this
> parameter be present? Is there any difficulty with that? Wouldn't the facet
> widget reuse that URL afterwards? Sorry for any possible misunderstanding
> on my end.
> >
> >
> > I did not go with this flow because of better performance since a
> separate async request will be made for change in each state. What I am
> doing now is that I take the map state on search or other events that
> reload the map asynchronously.Thanks for your suggestion Stephane. I could
> update the page by observing a change in each state. This is a little slow
> because the map will have to be reloaded for each state but still a good
> option.
>
> Ok great, looking forward to testing the new version
>
> Cheers
>
> Stéphane
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi all,

For the release of the application, in addition to the issues I have fixed
so far, I will make the popups smaller and possibly shift the search
control to a better location. Is there anything else that you feel is
important for the first release? If there is please let me know. Although I
will be working on the known issues and other suggestions put forward by
Stephane after the release.

I feel like it's important that we bring the application to the users soon
so there opinions can be gathered for user oriented development in the
future. I will also prepare the complete documentation over the weekend if
I can.

Thank you for all the support and suggestions so far. Especially Stephane.

Best,
Fawad


On Fri, Jul 12, 2019 at 4:07 PM Fawad Ali <[hidden email]> wrote:

> Hi all,
>
> I would go for small popups to start with (version 1.0), with a link to
>> the underlying XWiki page indeed. Later on, if time permits depending on
>> the priorities we decide, we could implement 1) a dynamic "more information
>> widget" that enlarges the popup dynamically, 2) a different interaction
>> mechanism that is similar to the Google Maps one. Let's add these features
>> as issues in Jira and refine the roadmap while defining the upcoming
>> versions, what do you think?
>>
>
> Stephane, as you suggest, let's go with smaller popups for now then. We
> can decide other placements later on if any.
>
> It will become a map item indeed, however, let's look closer at what
>> Airbnb is proposing: they typically manage three sheets:
>>
>> - One for the item page when displayed individually, for example:
>> https://up1.xwikisas.com/#0EcYpY5TQvlCAKuWP3AYIw
>> - One for displaying the item in a list:
>> https://up1.xwikisas.com/#yYiN8KfeKuy1BqibkgSkAA
>> - One for displaying the same item in a popup: same link, right side
>>
>> A customized class sheet would typically get used for the first display
>> as you envision it, but for the two others, which would be useful for
>> advanced maps imho, I was considering we could implement a built-in
>> mechanism allowing easy customization.
>>
>
> We could make it so that custom sheets can be used for displaying items in
> the popup. That way the user can create any sheet of his choice and use
> that. I will look into how this would be implemented.
>
> For now I am working on the issues you created so far. I will let you know
> how we could move forward from there.
>
> Thanks for your detailed suggestions, Stephane. It really helps in
> directing the application the right way. :)
>
> Best,
> Fawad
>
>
> On Thu, Jul 11, 2019 at 6:10 PM Stéphane Laurière <[hidden email]>
> wrote:
>
>>
>> Fawad,
>>
>> >     As a user, I like the Airbnb map experience with popups on top of
>> the markers, what about you?
>> >
>> >
>> > That is much like the default view of popups in Leaflet. This kind of
>> popup supports very little information, that's why I made a dedicated space
>> for popups. However, we could go with your suggestion of "view more". We
>> could either open the parent page with "view more" or fill the search
>> widget as you suggested. I would go with displaying more information in the
>> search widget. Is that fine with you?
>>
>> I would say that typical users will want to choose between displaying
>> information in a popup or over the search results panel, depending on the
>> user experience they prefer and the amount of information they want to
>> display. Typically, Google Maps and the Airbnb map have two different
>> approaches with this respect, and it would be a plus imho to implement the
>> two. Airbnb maps display popups, they are small indeed, but the image
>> slider lets the user obtain a significant amount of information. For
>> displaying more information like hotel schedule, ratings, comments, it's
>> clear that a bigger panel is useful, like what Google Maps is proposing.
>>
>> I would go for small popups to start with (version 1.0), with a link to
>> the underlying XWiki page indeed. Later on, if time permits depending on
>> the priorities we decide, we could implement 1) a dynamic "more information
>> widget" that enlarges the popup dynamically, 2) a different interaction
>> mechanism that is similar to the Google Maps one. Let's add these features
>> as issues in Jira and refine the roadmap while defining the upcoming
>> versions, what do you think?
>>
>> >     Along this line, another improvement (you probably have it in mind)
>> would be to introduce one or several dedicated sheets for such contextual
>> information so that it can get easily customized by users with development
>> skills.
>> >
>> >
>> > I do not think this is required. If a developer wants a custom display
>> for the popup information, he can create a class sheet and make pages with
>> that sheet and it will become a map item after adding location object to
>> the page.
>>
>> It will become a map item indeed, however, let's look closer at what
>> Airbnb is proposing: they typically manage three sheets:
>>
>> - One for the item page when displayed individually, for example:
>> https://up1.xwikisas.com/#0EcYpY5TQvlCAKuWP3AYIw
>> - One for displaying the item in a list:
>> https://up1.xwikisas.com/#yYiN8KfeKuy1BqibkgSkAA
>> - One for displaying the same item in a popup: same link, right side
>>
>> A customized class sheet would typically get used for the first display
>> as you envision it, but for the two others, which would be useful for
>> advanced maps imho, I was considering we could implement a built-in
>> mechanism allowing easy customization.
>>
>> >     Ok, we need to investigate this. I have a preliminary question
>> about this feature: how come that the URL does not reflect the mode status
>> when hitting the full screen button the first time? I mean, if I'm not
>> mistaken, when hitting the button before running any search, the URL
>> remains unchanged, while the user may want to use that URL to share the map
>> in full screen as is, or to embed it in full screen in a iframe, so
>> shouldn't this parameter be present? Is there any difficulty with that?
>> Wouldn't the facet widget reuse that URL afterwards? Sorry for any possible
>> misunderstanding on my end.
>> >
>> >
>> > I did not go with this flow because of better performance since a
>> separate async request will be made for change in each state. What I am
>> doing now is that I take the map state on search or other events that
>> reload the map asynchronously.Thanks for your suggestion Stephane. I could
>> update the page by observing a change in each state. This is a little slow
>> because the map will have to be reloaded for each state but still a good
>> option.
>>
>> Ok great, looking forward to testing the new version
>>
>> Cheers
>>
>> Stéphane
>>
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
In reply to this post by Fawad Ali
Hi Fawad,
 
> Also, I looked into it and the idea of custom class property for getting the location is interesting indeed. I will see how I should prioritize it and implement it then since we have other major features to look into.
>
> I would also like to ask; what do you foresee as the basic elements of the application? We have map configuration, map query, search and filter widget, markers and popups so far. Do you have anything other than this in mind that could be thought of as the basis of the application? I think we should completely stabilize the basics by the end of this week so I can work on other features like map paths, indoor maps and custom shapes.

Just a quick reply about this to confirm that I think the basic elements that you mention form the core of version 1.0. I don't have much to add at the moment. You're right that it's important to have sound foundations and we should limit future modifications of the core as much as possible, however despite anticipating the best we can, we may encounter the need to modify it at some point, let's see...

I saw you were facing issues with the release and the signing part, I hope we'll manage to solve them with the help of the community. Let's continue the discussion until we find a fix..

Cheers

Stéphane



Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Fawad Ali
Hi all,
Hope you are doing wonderful today.

I am very excited to announce that Interaction Maps Application v1.0 is now
up.

Extension and documentation:
https://extensions.xwiki.org/xwiki/bin/view/Extension/InteractiveMapsApplication/
Forum post:
https://forum.xwiki.org/t/interactive-maps-application-v1-0-released/

Thanks to Thomas for helping with issues in the release; Stephane for all
the wonderful and detailed instructions; Ecaterina for all the great help
and ideas; Vincent for helping with tests and other issues; and everyone
else who helped with the project.
It has been a wonderful experience so far to work with the XWiki community!
I look forward to how the complete application will turn out.

Best,
Fawad


On Tue, Jul 16, 2019 at 1:31 PM Stéphane Laurière <[hidden email]>
wrote:

> Hi Fawad,
>
> > Also, I looked into it and the idea of custom class property for getting
> the location is interesting indeed. I will see how I should prioritize it
> and implement it then since we have other major features to look into.
> >
> > I would also like to ask; what do you foresee as the basic elements of
> the application? We have map configuration, map query, search and filter
> widget, markers and popups so far. Do you have anything other than this in
> mind that could be thought of as the basis of the application? I think we
> should completely stabilize the basics by the end of this week so I can
> work on other features like map paths, indoor maps and custom shapes.
>
> Just a quick reply about this to confirm that I think the basic elements
> that you mention form the core of version 1.0. I don't have much to add at
> the moment. You're right that it's important to have sound foundations and
> we should limit future modifications of the core as much as possible,
> however despite anticipating the best we can, we may encounter the need to
> modify it at some point, let's see...
>
> I saw you were facing issues with the release and the signing part, I hope
> we'll manage to solve them with the help of the community. Let's continue
> the discussion until we find a fix..
>
> Cheers
>
> Stéphane
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Map Application - GSoC 19

Stéphane Laurière-6
Hi Fawad, That's great news, congratulations for this first release!

Cheers

Stéphane

> Hi all,
> Hope you are doing wonderful today.
>
> I am very excited to announce that Interaction Maps Application v1.0 is now up.
>
> Extension and documentation: https://extensions.xwiki.org/xwiki/bin/view/Extension/InteractiveMapsApplication/
> Forum post: https://forum.xwiki.org/t/interactive-maps-application-v1-0-released/
>
> Thanks to Thomas for helping with issues in the release; Stephane for all the wonderful and detailed instructions; Ecaterina for all the great help and ideas; Vincent for helping with tests and other issues; and everyone else who helped with the project.
> It has been a wonderful experience so far to work with the XWiki community! I look forward to how the complete application will turn out.
>
> Best,
> Fawad

1234567