Hi, Ali, and welcome to XWiki! Hope you'll have a great summer and enjoy discovering our product and being part of our community! Looking forward to see your project come to life. Best, Eduard On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) <[email protected]> wrote:

Hi ginpachi,

Thank you for introducing yourself and the project. Welcome to XWiki and enjoy this summer :)

Best, Caty

On Sun, May 12, 2019 at 6:46 PM Fawad Ali <[email protected]> wrote:

...

Hi everyone, Hope all of you are doing great.

About Me

I am Fawad Ali, selected as a student for Google Summer of Code. Currently enrolled in the 6th semester at University of Engineering and Technology, Taxila. I am a resident of Pakistan currently living in the city of Rawalpindi.

It is a great honor to have been selected and have a chance to work with XWiki. :)

*Profiles* GitHub - https://github.com/9inpachi LinkedIn - https://www.linkedin.com/in/fawadaliq/ Riot - @ginpachi:matrix.org

I will be presenting my project "Map Application" to all of you. Following are the relevant details.

Map Application

*Mentors: *Stéphane Laurière, Ecaterina Moraru

*Technologies:* JavaScript, Velocity, Java, Leaflet, other if required

Overview

This project is about the development of interactive maps in XWiki. Creation of an application within XWiki that will allow users to generate interactive maps which support collaboration and are easy to create so that locations can be shared, and areas can be associated with structured data.

This application will open several possibilities that can be utilized within XWiki and broaden the overall scope by allowing map rich wikis where locations and areas can be presented in a way that will increase the understandability of data.

It will also allow for the sharing of custom map related data which would be very helpful since users and admins will be able to present locations in an information rich map environment which will be interactive.

Features

...

*Markers and popups* - Place markers anywhere on the map and associate popups with them. *Path between two points* - A path will be generated by the application linking two points of interest. *Location search* - Search any location on the map. *Filtered list maps* - Allow the user to search for a specific kind of place (e.g. restaurants) and get a list of locations to choose from. Through the content available and binded to a location, the user will be able to learn some aspects of the location. *Custom shapes* - Custom shapes can be used to highlight a specific area for representation. The content associated with these shapes can give useful information about the area. *Indoor maps* - Such maps will be able to describe the internal structure or fair plan of a building or structure. They can be used to guide users in a big building and locate point of interests. *Maps on mobile* - Special design arrangements will be made for easily viewing of maps and availing all the features of the application on mobile devices. *Custom map backgrounds* - Custom backgrounds will make the environment of interactive maps much suitable for a specific purpose

If you have any features in mind that will make the Map Application better please feel free to reply to this mail. This is all for the summary of the project, if you want to have a more deeper insight, please check out the full proposal.

*Project Proposal: * https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr

Thanks for reading through the mail. I will be looking forward to your guidance through this summer and your contributions to the project. If you have any questions or suggestions, please feel free to reply to this mail.

Au revoir. :)

Best, Fawad Ali

On Mon, May 20, 2019 at 11:50 AM Fawad Ali <[email protected]> wrote:

Hi developers,

I have started working on the map application with some of the work done. So I wanted to get an update across to have a review of how I am doing so far. The source files for the project are available at: https://github.com/9inpachi/application-map I have been and in future intend to document the daily progress of the development. The progress is available at PROGRESS.md <https://github.com/9inpachi/application-map/blob/master/PROGRESS.md> within the repository,

The design proposal for the project is available at https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication.

And I would like to request a repository on xwiki-contrib.

Since you already have a repository the best would be to move it to xwiki-contrib instead of creating a new one. I think you need to make one of the xwiki-contrib organization owner the owner of your current repository to transfert it.

Best, Fawad

On Mon, May 13, 2019 at 6:50 PM Eduard Moraru <[email protected]> wrote:

...

Hi, Ali, and welcome to XWiki!

Hope you'll have a great summer and enjoy discovering our product and being part of our community!

Looking forward to see your project come to life.

Best, Eduard

On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi ginpachi,

Thank you for introducing yourself and the project. Welcome to XWiki and enjoy this summer :)

Best, Caty

On Sun, May 12, 2019 at 6:46 PM Fawad Ali <[email protected]> wrote:

...

Hi everyone, Hope all of you are doing great.

About Me

I am Fawad Ali, selected as a student for Google Summer of Code. Currently enrolled in the 6th semester at University of Engineering and Technology, Taxila. I am a resident of Pakistan currently living in the city of Rawalpindi.

It is a great honor to have been selected and have a chance to work with XWiki. :)

*Profiles* GitHub - https://github.com/9inpachi LinkedIn - https://www.linkedin.com/in/fawadaliq/ Riot - @ginpachi:matrix.org

I will be presenting my project "Map Application" to all of you. Following are the relevant details.

Map Application

*Mentors: *Stéphane Laurière, Ecaterina Moraru

*Technologies:* JavaScript, Velocity, Java, Leaflet, other if required

Overview

This project is about the development of interactive maps in XWiki. Creation of an application within XWiki that will allow users to generate interactive maps which support collaboration and are easy to create so that locations can be shared, and areas can be associated with structured data.

This application will open several possibilities that can be utilized within XWiki and broaden the overall scope by allowing map rich wikis where locations and areas can be presented in a way that will increase the understandability of data.

It will also allow for the sharing of custom map related data which would be very helpful since users and admins will be able to present locations in an information rich map environment which will be interactive.

Features

...

*Markers and popups* - Place markers anywhere on the map and associate popups with them. *Path between two points* - A path will be generated by the application linking two points of interest. *Location search* - Search any location on the map. *Filtered list maps* - Allow the user to search for a specific kind of place (e.g. restaurants) and get a list of locations to choose from. Through the content available and binded to a location, the user will be able to learn some aspects of the location. *Custom shapes* - Custom shapes can be used to highlight a specific area for representation. The content associated with these shapes can give useful information about the area. *Indoor maps* - Such maps will be able to describe the internal structure or fair plan of a building or structure. They can be used to guide users in a big building and locate point of interests. *Maps on mobile* - Special design arrangements will be made for easily viewing of maps and availing all the features of the application on mobile devices. *Custom map backgrounds* - Custom backgrounds will make the environment of interactive maps much suitable for a specific purpose

If you have any features in mind that will make the Map Application better please feel free to reply to this mail. This is all for the summary of the project, if you want to have a more deeper insight, please check out the full proposal.

*Project Proposal: * https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr

Thanks for reading through the mail. I will be looking forward to your guidance through this summer and your contributions to the project. If you have any questions or suggestions, please feel free to reply to this mail.

Au revoir. :)

Best, Fawad Ali

-- Thomas Mortagne

Eduard, Thanks for the heads up. I think I was focusing too much on the official documentation and forgot to take a look at the well documented pages for GSoC students. The repository has been moved to xwiki-contrib (thanks to Thomas for that). The updated link is: https://github.com/xwiki-contrib/application-map Thanks, Fawad On Mon, May 20, 2019 at 3:44 PM Eduard Moraru <[email protected]> wrote:

Hi, Fawad,

Please make double sure to read and follow the Student Guidelines, specially the section about the work process:

https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste...

It covers stuff like where to place your code (Contrib), how to document your process (project page), how to communicate, etc.

Otherwise, just from my quick "helicopter look", it looks like you're getting the hang of how to structure your project's code and how XWiki extensions work.

Keep it up, Eduard

On Mon, May 20, 2019 at 12:50 PM Fawad Ali <[email protected]> wrote:

...

Hi developers,

I have started working on the map application with some of the work done. So I wanted to get an update across to have a review of how I am doing so far. The source files for the project are available at: https://github.com/9inpachi/application-map I have been and in future intend to document the daily progress of the development. The progress is available at PROGRESS.md <https://github.com/9inpachi/application-map/blob/master/PROGRESS.md> within the repository,

The design proposal for the project is available at https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication.

And I would like to request a repository on xwiki-contrib.

Best, Fawad

On Mon, May 13, 2019 at 6:50 PM Eduard Moraru <[email protected]> wrote:

...

Hi, Ali, and welcome to XWiki!

Hope you'll have a great summer and enjoy discovering our product and being part of our community!

Looking forward to see your project come to life.

Best, Eduard

On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi ginpachi,

Thank you for introducing yourself and the project. Welcome to XWiki and enjoy this summer :)

Best, Caty

On Sun, May 12, 2019 at 6:46 PM Fawad Ali <[email protected]> wrote:

...

Hi everyone, Hope all of you are doing great.

About Me

I am Fawad Ali, selected as a student for Google Summer of Code. Currently enrolled in the 6th semester at University of Engineering and Technology, Taxila. I am a resident of Pakistan currently living in the city of Rawalpindi.

It is a great honor to have been selected and have a chance to work with XWiki. :)

*Profiles* GitHub - https://github.com/9inpachi LinkedIn - https://www.linkedin.com/in/fawadaliq/ Riot - @ginpachi:matrix.org

I will be presenting my project "Map Application" to all of you. Following are the relevant details.

Map Application

*Mentors: *Stéphane Laurière, Ecaterina Moraru

*Technologies:* JavaScript, Velocity, Java, Leaflet, other if required

Overview

This project is about the development of interactive maps in XWiki. Creation of an application within XWiki that will allow users to generate interactive maps which support collaboration and are easy to create so that locations can be shared, and areas can be associated with structured data.

This application will open several possibilities that can be utilized within XWiki and broaden the overall scope by allowing map rich wikis where locations and areas can be presented in a way that will increase the understandability of data.

It will also allow for the sharing of custom map related data which would be very helpful since users and admins will be able to present locations in an information rich map environment which will be interactive.

Features

...

*Markers and popups* - Place markers anywhere on the map and associate popups with them. *Path between two points* - A path will be generated by the application linking two points of interest. *Location search* - Search any location on the map. *Filtered list maps* - Allow the user to search for a specific kind of place (e.g. restaurants) and get a list of locations to choose from. Through the content available and binded to a location, the user will be able to learn some aspects of the location. *Custom shapes* - Custom shapes can be used to highlight a specific area for representation. The content associated with these shapes can give useful information about the area. *Indoor maps* - Such maps will be able to describe the internal structure or fair plan of a building or structure. They can be used to guide users in a big building and locate point of interests. *Maps on mobile* - Special design arrangements will be made for easily viewing of maps and availing all the features of the application on mobile devices. *Custom map backgrounds* - Custom backgrounds will make the environment of interactive maps much suitable for a specific purpose

If you have any features in mind that will make the Map Application better please feel free to reply to this mail. This is all for the summary of the project, if you want to have a more deeper insight, please check out the full proposal.

*Project Proposal: * https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr

Thanks for reading through the mail. I will be looking forward to your guidance through this summer and your contributions to the project. If you have any questions or suggestions, please feel free to reply to this mail.

Au revoir. :)

Best, Fawad Ali

Hi, It’s hard to choose without knowing how you position this app vs the existing map macro for example. What’s the proposal? Thanks -Vincent

On 20 May 2019, at 16:38, Ecaterina Moraru (Valica) <[email protected]> wrote:

Hi,

There were some concerns discussed about the naming of the app (since it's too generic). Alternatives suggested: - 'application-map-interactive' - 'application-interactivemap' - 'application-map-editor' - 'application-map-creator'

We should choose one form above and do the renames for GitHub and Jira asp.

Thanks, Caty

On Mon, May 20, 2019 at 2:28 PM Fawad Ali <[email protected]> wrote:

...

Eduard,

Thanks for the heads up. I think I was focusing too much on the official documentation and forgot to take a look at the well documented pages for GSoC students.

The repository has been moved to xwiki-contrib (thanks to Thomas for that). The updated link is: https://github.com/xwiki-contrib/application-map

Thanks, Fawad

On Mon, May 20, 2019 at 3:44 PM Eduard Moraru <[email protected]> wrote:

...

Hi, Fawad,

Please make double sure to read and follow the Student Guidelines, specially the section about the work process:

https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste...

...

It covers stuff like where to place your code (Contrib), how to document your process (project page), how to communicate, etc.

Otherwise, just from my quick "helicopter look", it looks like you're getting the hang of how to structure your project's code and how XWiki extensions work.

Keep it up, Eduard

On Mon, May 20, 2019 at 12:50 PM Fawad Ali <[email protected]> wrote:

...

Hi developers,

I have started working on the map application with some of the work

done.

...

...

So I wanted to get an update across to have a review of how I am doing so far. The source files for the project are available at: https://github.com/9inpachi/application-map I have been and in future intend to document the daily progress of the development. The progress is available at PROGRESS.md <https://github.com/9inpachi/application-map/blob/master/PROGRESS.md> within the repository,

The design proposal for the project is available at https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication.

And I would like to request a repository on xwiki-contrib.

Best, Fawad

On Mon, May 13, 2019 at 6:50 PM Eduard Moraru <[email protected]> wrote:

...

Hi, Ali, and welcome to XWiki!

Hope you'll have a great summer and enjoy discovering our product and being part of our community!

Looking forward to see your project come to life.

Best, Eduard

On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi ginpachi,

Thank you for introducing yourself and the project. Welcome to XWiki and enjoy this summer :)

Best, Caty

On Sun, May 12, 2019 at 6:46 PM Fawad Ali <[email protected]

...

...

wrote:

...

> Hi everyone, > Hope all of you are doing great. > > About Me > > I am Fawad Ali, selected as a student for Google Summer of Code. Currently > enrolled in the 6th semester at University of Engineering and

Technology,

...

> Taxila. I am a resident of Pakistan currently living in the city of > Rawalpindi. > > It is a great honor to have been selected and have a chance to work with > XWiki. :) > > *Profiles* > GitHub - https://github.com/9inpachi > LinkedIn - https://www.linkedin.com/in/fawadaliq/ > Riot - @ginpachi:matrix.org > > I will be presenting my project "Map Application" to all of you. Following > are the relevant details. > > > Map Application > > *Mentors: *Stéphane Laurière, Ecaterina Moraru > > *Technologies:* JavaScript, Velocity, Java, Leaflet, other if required > > Overview > > This project is about the development of interactive maps in XWiki. > Creation of an application within XWiki that will allow users to generate > interactive maps which support collaboration and are easy to create so that > locations can be shared, and areas can be associated with structured data. > > This application will open several possibilities that can be utilized > within XWiki and broaden the overall scope by allowing map rich wikis where > locations and areas can be presented in a way that will increase the > understandability of data. > > It will also allow for the sharing of custom map related data which would > be very helpful since users and admins will be able to present locations in > an information rich map environment which will be interactive. > > Features > >> *Markers and popups* - Place markers anywhere on the map and associate > popups with them. >> *Path between two points* - A path will be generated by the application > linking two points of interest. >> *Location search* - Search any location on the map. >> *Filtered list maps* - Allow the user to search for a specific kind of > place (e.g. restaurants) and get a list of locations to choose from. > Through the content available and binded to a location, the user will be > able to learn some aspects of the location. >> *Custom shapes* - Custom shapes can be used to highlight a specific area > for representation. The content associated with these shapes can give > useful information about the area. >> *Indoor maps* - Such maps will be able to describe the internal structure > or fair plan of a building or structure. They can be used to guide users in > a big building and locate point of interests. >> *Maps on mobile* - Special design arrangements will be made for easily > viewing of maps and availing all the features of the application on mobile > devices. >> *Custom map backgrounds* - Custom backgrounds will make the environment > of interactive maps much suitable for a specific purpose > > If you have any features in mind that will make the Map Application better > please feel free to reply to this mail. > This is all for the summary of the project, if you want to have a more > deeper insight, please check out the full proposal. > > *Project Proposal: * > https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr > > > Thanks for reading through the mail. I will be looking forward to your > guidance through this summer and your contributions to the project. > If you have any questions or suggestions, please feel free to reply to this > mail. > > Au revoir. :) > > Best, > Fawad Ali >

Ecaterina, Thanks for that. Vincent, regarding the macro the Interactive Maps Application. It will only be used to reference the maps that are already created with some tweaking options to go along. I will be focusing on the main features for now and will create the macro when we are somewhat in the middle of the project so I know which options the macro needs to have. Best, Fawad On Mon, May 20, 2019, 8:35 PM Ecaterina Moraru (Valica) <[email protected] wrote:

So I've updated to: "Interactive Maps Application" See: * https://jira.xwiki.org/projects/INTMAP/ * https://github.com/xwiki-contrib/application-interactive-maps

Thanks, Caty

On Mon, May 20, 2019 at 6:32 PM Vincent Massol <[email protected]> wrote:

...

Hi,

It’s hard to choose without knowing how you position this app vs the existing map macro for example. What’s the proposal?

Thanks -Vincent

...

On 20 May 2019, at 16:38, Ecaterina Moraru (Valica) <[email protected]

wrote:

...

Hi,

There were some concerns discussed about the naming of the app (since

it's

...

too generic). Alternatives suggested: - 'application-map-interactive' - 'application-interactivemap' - 'application-map-editor' - 'application-map-creator'

We should choose one form above and do the renames for GitHub and Jira asp.

Thanks, Caty

On Mon, May 20, 2019 at 2:28 PM Fawad Ali <[email protected]> wrote:

...

Eduard,

Thanks for the heads up. I think I was focusing too much on the official documentation and forgot to take a look at the well documented pages for GSoC students.

The repository has been moved to xwiki-contrib (thanks to Thomas for that). The updated link is: https://github.com/xwiki-contrib/application-map

Thanks, Fawad

On Mon, May 20, 2019 at 3:44 PM Eduard Moraru <[email protected]> wrote:

...

Hi, Fawad,

Please make double sure to read and follow the Student Guidelines, specially the section about the work process:

https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste...

...

...

...

...

It covers stuff like where to place your code (Contrib), how to

document

...

your process (project page), how to communicate, etc.

Otherwise, just from my quick "helicopter look", it looks like you're getting the hang of how to structure your project's code and how XWiki extensions work.

Keep it up, Eduard

On Mon, May 20, 2019 at 12:50 PM Fawad Ali <[email protected]> wrote:

...

Hi developers,

I have started working on the map application with some of the work done. So I wanted to get an update across to have a review of how I am doing so far. The source files for the project are available at: https://github.com/9inpachi/application-map I have been and in future intend to document the daily progress of the development. The progress is available at PROGRESS.md < https://github.com/9inpachi/application-map/blob/master/PROGRESS.md> within the repository,

The design proposal for the project is available at https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication.

And I would like to request a repository on xwiki-contrib.

Best, Fawad

On Mon, May 13, 2019 at 6:50 PM Eduard Moraru <[email protected]

...

...

...

...

wrote:

> Hi, Ali, and welcome to XWiki! > > Hope you'll have a great summer and enjoy discovering our product and being > part of our community! > > Looking forward to see your project come to life. > > Best, > Eduard > > On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) < > [email protected]> > wrote: > >> Hi ginpachi, >> >> Thank you for introducing yourself and the project. >> Welcome to XWiki and enjoy this summer :) >> >> Best, >> Caty >> >> On Sun, May 12, 2019 at 6:46 PM Fawad Ali < [email protected]

...

> wrote: >> >>> Hi everyone, >>> Hope all of you are doing great. >>> >>> About Me >>> >>> I am Fawad Ali, selected as a student for Google Summer of Code. >> Currently >>> enrolled in the 6th semester at University of Engineering and > Technology, >>> Taxila. I am a resident of Pakistan currently living in the city of >>> Rawalpindi. >>> >>> It is a great honor to have been selected and have a chance to work > with >>> XWiki. :) >>> >>> *Profiles* >>> GitHub - https://github.com/9inpachi >>> LinkedIn - https://www.linkedin.com/in/fawadaliq/ >>> Riot - @ginpachi:matrix.org >>> >>> I will be presenting my project "Map Application" to all of you. >> Following >>> are the relevant details. >>> >>> >>> Map Application >>> >>> *Mentors: *Stéphane Laurière, Ecaterina Moraru >>> >>> *Technologies:* JavaScript, Velocity, Java, Leaflet, other if required >>> >>> Overview >>> >>> This project is about the development of interactive maps in XWiki. >>> Creation of an application within XWiki that will allow users to > generate >>> interactive maps which support collaboration and are easy to create so >> that >>> locations can be shared, and areas can be associated with structured >> data. >>> >>> This application will open several possibilities that can be utilized >>> within XWiki and broaden the overall scope by allowing map rich wikis >> where >>> locations and areas can be presented in a way that will increase the >>> understandability of data. >>> >>> It will also allow for the sharing of custom map related data which > would >>> be very helpful since users and admins will be able to present > locations >> in >>> an information rich map environment which will be interactive. >>> >>> Features >>> >>>> *Markers and popups* - Place markers anywhere on the map and > associate >>> popups with them. >>>> *Path between two points* - A path will be generated by the > application >>> linking two points of interest. >>>> *Location search* - Search any location on the map. >>>> *Filtered list maps* - Allow the user to search for a specific kind > of >>> place (e.g. restaurants) and get a list of locations to choose from. >>> Through the content available and binded to a location, the user will > be >>> able to learn some aspects of the location. >>>> *Custom shapes* - Custom shapes can be used to highlight a specific >> area >>> for representation. The content associated with these shapes can give >>> useful information about the area. >>>> *Indoor maps* - Such maps will be able to describe the internal >> structure >>> or fair plan of a building or structure. They can be used to guide > users >> in >>> a big building and locate point of interests. >>>> *Maps on mobile* - Special design arrangements will be made for > easily >>> viewing of maps and availing all the features of the application on >> mobile >>> devices. >>>> *Custom map backgrounds* - Custom backgrounds will make the > environment >>> of interactive maps much suitable for a specific purpose >>> >>> If you have any features in mind that will make the Map Application >> better >>> please feel free to reply to this mail. >>> This is all for the summary of the project, if you want to have a more >>> deeper insight, please check out the full proposal. >>> >>> *Project Proposal: * >>> https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr >>> >>> >>> Thanks for reading through the mail. I will be looking forward to your >>> guidance through this summer and your contributions to the project. >>> If you have any questions or suggestions, please feel free to reply to >> this >>> mail. >>> >>> Au revoir. :) >>> >>> Best, >>> Fawad Ali >>> >> >

Hi developers, Hope you all are well. Interactive maps application's SNAPSHOT 1.0.2 is now available on GitHub. :) Link: https://github.com/xwiki-contrib/application-interactive-maps What has been done so far. - Markers and popups - Custom image support for markers - "xwiki/2.1" syntax support for popups - Simple forms for adding maps - Dedicated "Map Editor" for creating maps - Current location and location search controls - Generating routes between two points Maps can be created simply from Map.WebHome page or with the dedicated Map Editor for live preview. ToDo. - Implement WYSIWYG for "Popup Information" field (I have had some errors in doing it) - Compliance of code with XWiki standards (I should have done it from the start. Sorry about that.) Ecaterina and Stephane, I would like to ask you to evaluate how the application is so far. Your reviews will be highly appreciated. :) Best, Fawad On Mon, May 20, 2019 at 9:18 PM Vincent Massol <[email protected]> wrote:

Hi Fawad,

...

On 20 May 2019, at 18:12, Fawad Ali <[email protected]> wrote:

Ecaterina, Thanks for that.

Vincent, regarding the macro the Interactive Maps Application. It will only be used to reference the maps that are already created with some tweaking options to go along.

I will be focusing on the main features for now and will create the macro when we are somewhat in the middle of the project so I know which options the macro needs to have.

Ok thanks. I still think we should plan this as part of the architecture/design as otherwise you may make some assumption that won’t go in this right direction. Even if not implemented right now, at least you’d know where you’re going. If it’s too early then please think about it and try to answer it later but ASAP.

Thanks -Vincent

...

Best, Fawad

On Mon, May 20, 2019, 8:35 PM Ecaterina Moraru (Valica) < [email protected] wrote:

...

So I've updated to: "Interactive Maps Application" See: * https://jira.xwiki.org/projects/INTMAP/ * https://github.com/xwiki-contrib/application-interactive-maps

Thanks, Caty

On Mon, May 20, 2019 at 6:32 PM Vincent Massol <[email protected]> wrote:

...

Hi,

It’s hard to choose without knowing how you position this app vs the existing map macro for example. What’s the proposal?

Thanks -Vincent

...

On 20 May 2019, at 16:38, Ecaterina Moraru (Valica) < [email protected]

wrote:

...

Hi,

There were some concerns discussed about the naming of the app (since

it's

...

too generic). Alternatives suggested: - 'application-map-interactive' - 'application-interactivemap' - 'application-map-editor' - 'application-map-creator'

We should choose one form above and do the renames for GitHub and Jira asp.

Thanks, Caty

On Mon, May 20, 2019 at 2:28 PM Fawad Ali <[email protected]> wrote:

...

Eduard,

Thanks for the heads up. I think I was focusing too much on the official documentation and forgot to take a look at the well documented pages for GSoC students.

The repository has been moved to xwiki-contrib (thanks to Thomas for that). The updated link is: https://github.com/xwiki-contrib/application-map

Thanks, Fawad

On Mon, May 20, 2019 at 3:44 PM Eduard Moraru <[email protected]> wrote:

> Hi, Fawad, > > Please make double sure to read and follow the Student Guidelines, > specially the section about the work process: > > >

https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste...

...

...

...

...

> > It covers stuff like where to place your code (Contrib), how to document > your process (project page), how to communicate, etc. > > Otherwise, just from my quick "helicopter look", it looks like you're > getting the hang of how to structure your project's code and how XWiki > extensions work. > > Keep it up, > Eduard > > On Mon, May 20, 2019 at 12:50 PM Fawad Ali <[email protected]

...

...

...

...

> wrote: > >> Hi developers, >> >> I have started working on the map application with some of the work done. >> So I wanted to get an update across to have a review of how I am doing so >> far. >> The source files for the project are available at: >> https://github.com/9inpachi/application-map >> I have been and in future intend to document the daily progress of the >> development. The progress is available at PROGRESS.md >> < https://github.com/9inpachi/application-map/blob/master/PROGRESS.md> >> within >> the repository, >> >> The design proposal for the project is available at >> https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication. >> >> And I would like to request a repository on xwiki-contrib. >> >> Best, >> Fawad >> >> >> On Mon, May 13, 2019 at 6:50 PM Eduard Moraru < [email protected]

...

...

>> wrote: >> >>> Hi, Ali, and welcome to XWiki! >>> >>> Hope you'll have a great summer and enjoy discovering our product and >> being >>> part of our community! >>> >>> Looking forward to see your project come to life. >>> >>> Best, >>> Eduard >>> >>> On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) < >>> [email protected]> >>> wrote: >>> >>>> Hi ginpachi, >>>> >>>> Thank you for introducing yourself and the project. >>>> Welcome to XWiki and enjoy this summer :) >>>> >>>> Best, >>>> Caty >>>> >>>> On Sun, May 12, 2019 at 6:46 PM Fawad Ali < [email protected] > >>> wrote: >>>> >>>>> Hi everyone, >>>>> Hope all of you are doing great. >>>>> >>>>> About Me >>>>> >>>>> I am Fawad Ali, selected as a student for Google Summer of Code. >>>> Currently >>>>> enrolled in the 6th semester at University of Engineering and >>> Technology, >>>>> Taxila. I am a resident of Pakistan currently living in the city of >>>>> Rawalpindi. >>>>> >>>>> It is a great honor to have been selected and have a chance to work >>> with >>>>> XWiki. :) >>>>> >>>>> *Profiles* >>>>> GitHub - https://github.com/9inpachi >>>>> LinkedIn - https://www.linkedin.com/in/fawadaliq/ >>>>> Riot - @ginpachi:matrix.org >>>>> >>>>> I will be presenting my project "Map Application" to all of you. >>>> Following >>>>> are the relevant details. >>>>> >>>>> >>>>> Map Application >>>>> >>>>> *Mentors: *Stéphane Laurière, Ecaterina Moraru >>>>> >>>>> *Technologies:* JavaScript, Velocity, Java, Leaflet, other if >> required >>>>> >>>>> Overview >>>>> >>>>> This project is about the development of interactive maps in XWiki. >>>>> Creation of an application within XWiki that will allow users to >>> generate >>>>> interactive maps which support collaboration and are easy to create >> so >>>> that >>>>> locations can be shared, and areas can be associated with > structured >>>> data. >>>>> >>>>> This application will open several possibilities that can be > utilized >>>>> within XWiki and broaden the overall scope by allowing map rich > wikis >>>> where >>>>> locations and areas can be presented in a way that will increase > the >>>>> understandability of data. >>>>> >>>>> It will also allow for the sharing of custom map related data which >>> would >>>>> be very helpful since users and admins will be able to present >>> locations >>>> in >>>>> an information rich map environment which will be interactive. >>>>> >>>>> Features >>>>> >>>>>> *Markers and popups* - Place markers anywhere on the map and >>> associate >>>>> popups with them. >>>>>> *Path between two points* - A path will be generated by the >>> application >>>>> linking two points of interest. >>>>>> *Location search* - Search any location on the map. >>>>>> *Filtered list maps* - Allow the user to search for a specific > kind >>> of >>>>> place (e.g. restaurants) and get a list of locations to choose > from. >>>>> Through the content available and binded to a location, the user > will >>> be >>>>> able to learn some aspects of the location. >>>>>> *Custom shapes* - Custom shapes can be used to highlight a > specific >>>> area >>>>> for representation. The content associated with these shapes can > give >>>>> useful information about the area. >>>>>> *Indoor maps* - Such maps will be able to describe the internal >>>> structure >>>>> or fair plan of a building or structure. They can be used to guide >>> users >>>> in >>>>> a big building and locate point of interests. >>>>>> *Maps on mobile* - Special design arrangements will be made for >>> easily >>>>> viewing of maps and availing all the features of the application on >>>> mobile >>>>> devices. >>>>>> *Custom map backgrounds* - Custom backgrounds will make the >>> environment >>>>> of interactive maps much suitable for a specific purpose >>>>> >>>>> If you have any features in mind that will make the Map Application >>>> better >>>>> please feel free to reply to this mail. >>>>> This is all for the summary of the project, if you want to have a >> more >>>>> deeper insight, please check out the full proposal. >>>>> >>>>> *Project Proposal: * >>>>> https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr >>>>> >>>>> >>>>> Thanks for reading through the mail. I will be looking forward to >> your >>>>> guidance through this summer and your contributions to the project. >>>>> If you have any questions or suggestions, please feel free to reply >> to >>>> this >>>>> mail. >>>>> >>>>> Au revoir. :) >>>>> >>>>> Best, >>>>> Fawad Ali >>>>> >>>> >>> >> >

Should I create jira issues for any updates I do during development? I made my commits like INTMAP-R<number> for each revision I did. For simple commits like changing the Progress.md file or a line or two in pom.xml, do I use "[Misc]" for identifying the commit? 8.4-6 is the default version on https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/Creati... so I did not change that. It is changed to 11.1 after the fix with encoding issues. Thanks for that. I was using the snapshots version to mark the completion of every major function. Mainly a simple map and a path map for now so the version 1.0.2. I would like to know if snapshots are supposed to be released. For the URL path Map/Maps do you have a better path in mind for the created maps? I think its right when all the other paths are hidden for the user. I will be sure to provide screenshots for the next time. :) For combining all the maps in a single livetable, I have a perspective that for this application, every map is of a "kind" like a "path map" or "simple map" or later on "filtered list map". So I separated the maps based on that perspective. WDYT? Should I treat all the maps same? Thankfully, the Map Macro uses the Macros.MapMacro space so we are safe for that. For the creation options, should I create a single template for the "Add" button and separate the map editors with tabs? If I create a template for each kind of map, the templates will become bulky I think. I also wanted to talk about filtered list maps so that I can move on with the development. Stephane sent me a link in the talks we had prior to this. https://napoleon-sainte-helene.plan-interactif.com/en/#!/category/886826/@-1... What kind of options do you have in mind for the filterable list? A general flow would really help me in direction. Thanks. :) Best, Fawad On Fri, May 24, 2019 at 10:02 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

Some notes:

- Please create issues in JIRA and commit over the issues,

https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HRule:Al...

- Why did you chose the 8.4-6 parent?

- pom version should not be 1.0.2-SNAPSHOT , since you didn't had any previous release

- I don't have the errors you've pasted when doing mvn xar:format. For me it adds only a single space. What OS are you using? Maybe try to clean your environment? Not really sure what to suggest, especially since enygma didn't reproduce the problem either.

- It's a bit strange the Map/Maps URL path. - Currently it works nicely. Would have been easier to provide some screenshots in order to make people want to test the app :)

- in terms of UX, we will need to combine: -- all the maps in a single livetable, -- under the same 'Map' space (careful - please test the Map Macro and don't have conflicts on the space name) -- the create should be done from the 'Add' button, using templates / sheets

I haven't had a chance to look at the code yet. But just wanted to give you a response / feedback: it looks good for now. You did a great job :)

We need to discuss with Stephane and see exactly what use cases he wants to cover.

Have a great week-end, Caty

On Thu, May 23, 2019 at 1:37 PM Fawad Ali <[email protected]> wrote:

...

Hi developers, Hope you all are well.

Interactive maps application's SNAPSHOT 1.0.2 is now available on GitHub. :) Link: https://github.com/xwiki-contrib/application-interactive-maps

What has been done so far. - Markers and popups - Custom image support for markers - "xwiki/2.1" syntax support for popups - Simple forms for adding maps - Dedicated "Map Editor" for creating maps - Current location and location search controls - Generating routes between two points

Maps can be created simply from Map.WebHome page or with the dedicated Map Editor for live preview.

ToDo. - Implement WYSIWYG for "Popup Information" field (I have had some errors in doing it) - Compliance of code with XWiki standards (I should have done it from the start. Sorry about that.)

Ecaterina and Stephane, I would like to ask you to evaluate how the application is so far. Your reviews will be highly appreciated. :)

Best, Fawad

On Mon, May 20, 2019 at 9:18 PM Vincent Massol <[email protected]> wrote:

...

Hi Fawad,

...

On 20 May 2019, at 18:12, Fawad Ali <[email protected]> wrote:

Ecaterina, Thanks for that.

Vincent, regarding the macro the Interactive Maps Application. It will only be used to reference the maps that are already created with some tweaking options to go along.

I will be focusing on the main features for now and will create the macro when we are somewhat in the middle of the project so I know which options the macro needs to have.

Ok thanks. I still think we should plan this as part of the architecture/design as otherwise you may make some assumption that won’t go in this right direction. Even if not implemented right now, at least you’d know where you’re going. If it’s too early then please think about it and try to answer it later but ASAP.

Thanks -Vincent

...

Best, Fawad

On Mon, May 20, 2019, 8:35 PM Ecaterina Moraru (Valica) < [email protected] wrote:

...

So I've updated to: "Interactive Maps Application" See: * https://jira.xwiki.org/projects/INTMAP/ * https://github.com/xwiki-contrib/application-interactive-maps

Thanks, Caty

On Mon, May 20, 2019 at 6:32 PM Vincent Massol <[email protected]> wrote:

...

Hi,

It’s hard to choose without knowing how you position this app vs the existing map macro for example. What’s the proposal?

Thanks -Vincent

> On 20 May 2019, at 16:38, Ecaterina Moraru (Valica) < [email protected]

wrote: > > Hi, > > There were some concerns discussed about the naming of the app (since it's > too generic). > Alternatives suggested: > - 'application-map-interactive' > - 'application-interactivemap' > - 'application-map-editor' > - 'application-map-creator' > > We should choose one form above and do the renames for GitHub and Jira asp. > > Thanks, > Caty > > On Mon, May 20, 2019 at 2:28 PM Fawad Ali < [email protected]> wrote: > >> Eduard, >> >> Thanks for the heads up. I think I was focusing too much on the official >> documentation and forgot to take a look at the well documented pages for >> GSoC students. >> >> The repository has been moved to xwiki-contrib (thanks to Thomas for that). >> The updated link is: https://github.com/xwiki-contrib/application-map >> >> Thanks, >> Fawad >> >> >> On Mon, May 20, 2019 at 3:44 PM Eduard Moraru < [email protected]> >> wrote: >> >>> Hi, Fawad, >>> >>> Please make double sure to read and follow the Student Guidelines, >>> specially the section about the work process: >>> >>> >>> >>

https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste...

...

...

...

...

...

>>> >>> It covers stuff like where to place your code (Contrib), how to document >>> your process (project page), how to communicate, etc. >>> >>> Otherwise, just from my quick "helicopter look", it looks like you're >>> getting the hang of how to structure your project's code and how XWiki >>> extensions work. >>> >>> Keep it up, >>> Eduard >>> >>> On Mon, May 20, 2019 at 12:50 PM Fawad Ali < [email protected]

...

...

>>> wrote: >>> >>>> Hi developers, >>>> >>>> I have started working on the map application with some of the work >> done. >>>> So I wanted to get an update across to have a review of how I am doing >> so >>>> far. >>>> The source files for the project are available at: >>>> https://github.com/9inpachi/application-map >>>> I have been and in future intend to document the daily progress of the >>>> development. The progress is available at PROGRESS.md >>>> < https://github.com/9inpachi/application-map/blob/master/PROGRESS.md

...

...

...

...

>>>> within >>>> the repository, >>>> >>>> The design proposal for the project is available at >>>> https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication. >>>> >>>> And I would like to request a repository on xwiki-contrib. >>>> >>>> Best, >>>> Fawad >>>> >>>> >>>> On Mon, May 13, 2019 at 6:50 PM Eduard Moraru < [email protected]

>>>> wrote: >>>> >>>>> Hi, Ali, and welcome to XWiki! >>>>> >>>>> Hope you'll have a great summer and enjoy discovering our product and >>>> being >>>>> part of our community! >>>>> >>>>> Looking forward to see your project come to life. >>>>> >>>>> Best, >>>>> Eduard >>>>> >>>>> On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) < >>>>> [email protected]> >>>>> wrote: >>>>> >>>>>> Hi ginpachi, >>>>>> >>>>>> Thank you for introducing yourself and the project. >>>>>> Welcome to XWiki and enjoy this summer :) >>>>>> >>>>>> Best, >>>>>> Caty >>>>>> >>>>>> On Sun, May 12, 2019 at 6:46 PM Fawad Ali < [email protected] >>> >>>>> wrote: >>>>>> >>>>>>> Hi everyone, >>>>>>> Hope all of you are doing great. >>>>>>> >>>>>>> About Me >>>>>>> >>>>>>> I am Fawad Ali, selected as a student for Google Summer of Code. >>>>>> Currently >>>>>>> enrolled in the 6th semester at University of Engineering and >>>>> Technology, >>>>>>> Taxila. I am a resident of Pakistan currently living in the city >> of >>>>>>> Rawalpindi. >>>>>>> >>>>>>> It is a great honor to have been selected and have a chance to >> work >>>>> with >>>>>>> XWiki. :) >>>>>>> >>>>>>> *Profiles* >>>>>>> GitHub - https://github.com/9inpachi >>>>>>> LinkedIn - https://www.linkedin.com/in/fawadaliq/ >>>>>>> Riot - @ginpachi:matrix.org >>>>>>> >>>>>>> I will be presenting my project "Map Application" to all of you. >>>>>> Following >>>>>>> are the relevant details. >>>>>>> >>>>>>> >>>>>>> Map Application >>>>>>> >>>>>>> *Mentors: *Stéphane Laurière, Ecaterina Moraru >>>>>>> >>>>>>> *Technologies:* JavaScript, Velocity, Java, Leaflet, other if >>>> required >>>>>>> >>>>>>> Overview >>>>>>> >>>>>>> This project is about the development of interactive maps in >> XWiki. >>>>>>> Creation of an application within XWiki that will allow users to >>>>> generate >>>>>>> interactive maps which support collaboration and are easy to >> create >>>> so >>>>>> that >>>>>>> locations can be shared, and areas can be associated with >>> structured >>>>>> data. >>>>>>> >>>>>>> This application will open several possibilities that can be >>> utilized >>>>>>> within XWiki and broaden the overall scope by allowing map rich >>> wikis >>>>>> where >>>>>>> locations and areas can be presented in a way that will increase >>> the >>>>>>> understandability of data. >>>>>>> >>>>>>> It will also allow for the sharing of custom map related data >> which >>>>> would >>>>>>> be very helpful since users and admins will be able to present >>>>> locations >>>>>> in >>>>>>> an information rich map environment which will be interactive. >>>>>>> >>>>>>> Features >>>>>>> >>>>>>>> *Markers and popups* - Place markers anywhere on the map and >>>>> associate >>>>>>> popups with them. >>>>>>>> *Path between two points* - A path will be generated by the >>>>> application >>>>>>> linking two points of interest. >>>>>>>> *Location search* - Search any location on the map. >>>>>>>> *Filtered list maps* - Allow the user to search for a specific >>> kind >>>>> of >>>>>>> place (e.g. restaurants) and get a list of locations to choose >>> from. >>>>>>> Through the content available and binded to a location, the user >>> will >>>>> be >>>>>>> able to learn some aspects of the location. >>>>>>>> *Custom shapes* - Custom shapes can be used to highlight a >>> specific >>>>>> area >>>>>>> for representation. The content associated with these shapes can >>> give >>>>>>> useful information about the area. >>>>>>>> *Indoor maps* - Such maps will be able to describe the internal >>>>>> structure >>>>>>> or fair plan of a building or structure. They can be used to >> guide >>>>> users >>>>>> in >>>>>>> a big building and locate point of interests. >>>>>>>> *Maps on mobile* - Special design arrangements will be made for >>>>> easily >>>>>>> viewing of maps and availing all the features of the application >> on >>>>>> mobile >>>>>>> devices. >>>>>>>> *Custom map backgrounds* - Custom backgrounds will make the >>>>> environment >>>>>>> of interactive maps much suitable for a specific purpose >>>>>>> >>>>>>> If you have any features in mind that will make the Map >> Application >>>>>> better >>>>>>> please feel free to reply to this mail. >>>>>>> This is all for the summary of the project, if you want to have a >>>> more >>>>>>> deeper insight, please check out the full proposal. >>>>>>> >>>>>>> *Project Proposal: * >>>>>>> >> https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr >>>>>>> >>>>>>> >>>>>>> Thanks for reading through the mail. I will be looking forward to >>>> your >>>>>>> guidance through this summer and your contributions to the >> project. >>>>>>> If you have any questions or suggestions, please feel free to >> reply >>>> to >>>>>> this >>>>>>> mail. >>>>>>> >>>>>>> Au revoir. :) >>>>>>> >>>>>>> Best, >>>>>>> Fawad Ali >>>>>>> >>>>>> >>>>> >>>> >>> >>

Hi, Hope all are doing well. Extremely thanks for the information Ecaterina. It really helps. :) I am trying to make filterable list maps but I am more or less stuck. This is what I have done so far: [image: image.png] So what I have in mind for this is that each marker will have a category and a custom popup. Then we can have custom marker image for each of the category or for each of the marker separately. I wanted to have forms directly inside the popup but that does not seem to be possible giving how popups in leaflet work. This is a little afar from what I observe in https://napoleon-sainte-helene.plan-interactif.com and I am unable to think of a better way to manage everything. Stephane or Ecaterina, if you have a better approach and flow for this then please let me know. And Stephane, your help would be highly appreciable. Thanks. Best, Fawad On Mon, May 27, 2019 at 6:03 PM Ecaterina Moraru (Valica) <[email protected]> wrote:

On Fri, May 24, 2019 at 9:19 PM Fawad Ali <[email protected]> wrote:

...

Should I create jira issues for any updates I do during development? I made my commits like INTMAP-R<number> for each revision I did. For simple commits like changing the Progress.md file or a line or two in pom.xml, do I use "[Misc]" for identifying the commit?

All the code commits need to be associated with an issue. The reason is also practical: when you look at the blame, you will easily identify the issue, and the issue will list screenshots, multiple commits, related issues, etc.

Keep [misc] just for edge cases or exceptions, but the Progress.md is not code, so you don't need an issue for that. Still, it's a bit strange to have the progress in gitHub, since it's more project management, than code. When you will release the application, that page will able be part of the release. Alternatively, you could keep the progress in a design page, but it's also up to you.

...

8.4-6 is the default version on

https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Tutorials/Creati...

...

so I did not change that. It is changed to 11.1 after the fix with encoding issues. Thanks for that.

On the community side, we support just 3 version (see https://www.xwiki.org/xwiki/bin/view/Main/Support#HSupportedVersions). So in practice, new applications should support at least the LTS. Our current LTS is 10.11.8 (so 10.11.x). The 8.x version in .pom was just an example. You should also try to see if you have the same encoding issues with 10.11.x versions, if not, use that as a parent.

...

I was using the snapshots version to mark the completion of every major function. Mainly a simple map and a path map for now so the version

1.0.2.

...

I would like to know if snapshots are supposed to be released.

"every major functions" will be tracked in issues, not in the project version. We don't release snapshots versions. Snapshots builds are used when continuous integration is enabled. More at

https://dev.xwiki.org/xwiki/bin/view/Community/VersioningAndReleasePractices... . You project releases should start at 1.0, etc.

...

For the URL path Map/Maps do you have a better path in mind for the

created

...

maps? I think its right when all the other paths are hidden for the user.

the URL should be as short as possible for the end-user and semantic. If you have 'Map' in the breadcrumb, the user will go in each parent to see functionality.

...

I will be sure to provide screenshots for the next time. :)

Easier to review and to get traction. Thanks :)

...

For combining all the maps in a single livetable, I have a perspective

that

...

for this application, every map is of a "kind" like a "path map" or "simple map" or later on "filtered list map". So I separated the maps based on that perspective. WDYT? Should I treat all the maps same?

We need Stephane 's opinion since he was the one that proposed the project, so he knows better the use cases.

...

Thankfully, the Map Macro uses the Macros.MapMacro space so we are safe for that.

For the creation options, should I create a single template for the "Add" button and separate the map editors with tabs? If I create a template for each kind of map, the templates will become bulky I think.

You could select the type of map you want from a checkbox in the create sheet. I would unify as much as possible the way to create maps.

...

I also wanted to talk about filtered list maps so that I can move on with the development. Stephane sent me a link in the talks we had prior to

this.

...

https://napoleon-sainte-helene.plan-interactif.com/en/#!/category/886826/@-1...

...

What kind of options do you have in mind for the filterable list? A

general

...

flow would really help me in direction.

Stephane?

...

Thanks. :)

Thanks, Caty

...

Best, Fawad

On Fri, May 24, 2019 at 10:02 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Some notes:

- Please create issues in JIRA and commit over the issues,

https://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HRule:Al...

...

...

- Why did you chose the 8.4-6 parent?

- pom version should not be 1.0.2-SNAPSHOT , since you didn't had any previous release

- I don't have the errors you've pasted when doing mvn xar:format. For

me

...

it adds only a single space. What OS are you using? Maybe try to clean your environment? Not really sure what to suggest, especially since enygma didn't reproduce the problem either.

- It's a bit strange the Map/Maps URL path. - Currently it works nicely. Would have been easier to provide some screenshots in order to make people want to test the app :)

- in terms of UX, we will need to combine: -- all the maps in a single livetable, -- under the same 'Map' space (careful - please test the Map Macro and don't have conflicts on the space name) -- the create should be done from the 'Add' button, using templates / sheets

I haven't had a chance to look at the code yet. But just wanted to give you a response / feedback: it looks good for now. You did a great job :)

We need to discuss with Stephane and see exactly what use cases he wants to cover.

Have a great week-end, Caty

On Thu, May 23, 2019 at 1:37 PM Fawad Ali <[email protected]> wrote:

...

Hi developers, Hope you all are well.

Interactive maps application's SNAPSHOT 1.0.2 is now available on GitHub. :) Link: https://github.com/xwiki-contrib/application-interactive-maps

What has been done so far. - Markers and popups - Custom image support for markers - "xwiki/2.1" syntax support for popups - Simple forms for adding maps - Dedicated "Map Editor" for creating maps - Current location and location search controls - Generating routes between two points

Maps can be created simply from Map.WebHome page or with the dedicated Map Editor for live preview.

ToDo. - Implement WYSIWYG for "Popup Information" field (I have had some errors in doing it) - Compliance of code with XWiki standards (I should have done it from the start. Sorry about that.)

Ecaterina and Stephane, I would like to ask you to evaluate how the application is so far. Your reviews will be highly appreciated. :)

Best, Fawad

On Mon, May 20, 2019 at 9:18 PM Vincent Massol <[email protected]> wrote:

...

Hi Fawad,

...

On 20 May 2019, at 18:12, Fawad Ali <[email protected]> wrote:

Ecaterina, Thanks for that.

Vincent, regarding the macro the Interactive Maps Application. It will only be used to reference the maps that are already created with some tweaking options to go along.

I will be focusing on the main features for now and will create the macro when we are somewhat in the middle of the project so I know which options the macro needs to have.

Ok thanks. I still think we should plan this as part of the architecture/design as otherwise you may make some assumption that won’t go in this right direction. Even if not implemented right now, at least you’d know where you’re going. If it’s too early then please think about it and try to answer it later but ASAP.

Thanks -Vincent

...

Best, Fawad

On Mon, May 20, 2019, 8:35 PM Ecaterina Moraru (Valica) < [email protected] wrote:

> So I've updated to: "Interactive Maps Application" > See: > * https://jira.xwiki.org/projects/INTMAP/ > * https://github.com/xwiki-contrib/application-interactive-maps > > Thanks, > Caty > > On Mon, May 20, 2019 at 6:32 PM Vincent Massol < [email protected]> wrote: > >> Hi, >> >> It’s hard to choose without knowing how you position this app vs the >> existing map macro for example. What’s the proposal? >> >> Thanks >> -Vincent >> >>> On 20 May 2019, at 16:38, Ecaterina Moraru (Valica) < [email protected] >> >> wrote: >>> >>> Hi, >>> >>> There were some concerns discussed about the naming of the app (since >> it's >>> too generic). >>> Alternatives suggested: >>> - 'application-map-interactive' >>> - 'application-interactivemap' >>> - 'application-map-editor' >>> - 'application-map-creator' >>> >>> We should choose one form above and do the renames for GitHub and Jira >> asp. >>> >>> Thanks, >>> Caty >>> >>> On Mon, May 20, 2019 at 2:28 PM Fawad Ali < [email protected]> >> wrote: >>> >>>> Eduard, >>>> >>>> Thanks for the heads up. I think I was focusing too much on the > official >>>> documentation and forgot to take a look at the well documented pages > for >>>> GSoC students. >>>> >>>> The repository has been moved to xwiki-contrib (thanks to Thomas for >> that). >>>> The updated link is: > https://github.com/xwiki-contrib/application-map >>>> >>>> Thanks, >>>> Fawad >>>> >>>> >>>> On Mon, May 20, 2019 at 3:44 PM Eduard Moraru < [email protected]> >>>> wrote: >>>> >>>>> Hi, Fawad, >>>>> >>>>> Please make double sure to read and follow the Student Guidelines, >>>>> specially the section about the work process: >>>>> >>>>> >>>>> >>>> >> >

https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Guidelines#HSuggeste...

...

...

...

...

...

>>>>> >>>>> It covers stuff like where to place your code (Contrib), how to >> document >>>>> your process (project page), how to communicate, etc. >>>>> >>>>> Otherwise, just from my quick "helicopter look", it looks like you're >>>>> getting the hang of how to structure your project's code and how > XWiki >>>>> extensions work. >>>>> >>>>> Keep it up, >>>>> Eduard >>>>> >>>>> On Mon, May 20, 2019 at 12:50 PM Fawad Ali < [email protected]

>>>>> wrote: >>>>> >>>>>> Hi developers, >>>>>> >>>>>> I have started working on the map application with some of the work >>>> done. >>>>>> So I wanted to get an update across to have a review of how I am > doing >>>> so >>>>>> far. >>>>>> The source files for the project are available at: >>>>>> https://github.com/9inpachi/application-map >>>>>> I have been and in future intend to document the daily progress of > the >>>>>> development. The progress is available at PROGRESS.md >>>>>> < > https://github.com/9inpachi/application-map/blob/master/PROGRESS.md

...

...

>>>>>> within >>>>>> the repository, >>>>>> >>>>>> The design proposal for the project is available at >>>>>> https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication. >>>>>> >>>>>> And I would like to request a repository on xwiki-contrib. >>>>>> >>>>>> Best, >>>>>> Fawad >>>>>> >>>>>> >>>>>> On Mon, May 13, 2019 at 6:50 PM Eduard Moraru < [email protected] >> >>>>>> wrote: >>>>>> >>>>>>> Hi, Ali, and welcome to XWiki! >>>>>>> >>>>>>> Hope you'll have a great summer and enjoy discovering our product > and >>>>>> being >>>>>>> part of our community! >>>>>>> >>>>>>> Looking forward to see your project come to life. >>>>>>> >>>>>>> Best, >>>>>>> Eduard >>>>>>> >>>>>>> On Mon, May 13, 2019 at 4:00 PM Ecaterina Moraru (Valica) < >>>>>>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi ginpachi, >>>>>>>> >>>>>>>> Thank you for introducing yourself and the project. >>>>>>>> Welcome to XWiki and enjoy this summer :) >>>>>>>> >>>>>>>> Best, >>>>>>>> Caty >>>>>>>> >>>>>>>> On Sun, May 12, 2019 at 6:46 PM Fawad Ali < > [email protected] >>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi everyone, >>>>>>>>> Hope all of you are doing great. >>>>>>>>> >>>>>>>>> About Me >>>>>>>>> >>>>>>>>> I am Fawad Ali, selected as a student for Google Summer of Code. >>>>>>>> Currently >>>>>>>>> enrolled in the 6th semester at University of Engineering and >>>>>>> Technology, >>>>>>>>> Taxila. I am a resident of Pakistan currently living in the city >>>> of >>>>>>>>> Rawalpindi. >>>>>>>>> >>>>>>>>> It is a great honor to have been selected and have a chance to >>>> work >>>>>>> with >>>>>>>>> XWiki. :) >>>>>>>>> >>>>>>>>> *Profiles* >>>>>>>>> GitHub - https://github.com/9inpachi >>>>>>>>> LinkedIn - https://www.linkedin.com/in/fawadaliq/ >>>>>>>>> Riot - @ginpachi:matrix.org >>>>>>>>> >>>>>>>>> I will be presenting my project "Map Application" to all of you. >>>>>>>> Following >>>>>>>>> are the relevant details. >>>>>>>>> >>>>>>>>> >>>>>>>>> Map Application >>>>>>>>> >>>>>>>>> *Mentors: *Stéphane Laurière, Ecaterina Moraru >>>>>>>>> >>>>>>>>> *Technologies:* JavaScript, Velocity, Java, Leaflet, other if >>>>>> required >>>>>>>>> >>>>>>>>> Overview >>>>>>>>> >>>>>>>>> This project is about the development of interactive maps in >>>> XWiki. >>>>>>>>> Creation of an application within XWiki that will allow users to >>>>>>> generate >>>>>>>>> interactive maps which support collaboration and are easy to >>>> create >>>>>> so >>>>>>>> that >>>>>>>>> locations can be shared, and areas can be associated with >>>>> structured >>>>>>>> data. >>>>>>>>> >>>>>>>>> This application will open several possibilities that can be >>>>> utilized >>>>>>>>> within XWiki and broaden the overall scope by allowing map rich >>>>> wikis >>>>>>>> where >>>>>>>>> locations and areas can be presented in a way that will increase >>>>> the >>>>>>>>> understandability of data. >>>>>>>>> >>>>>>>>> It will also allow for the sharing of custom map related data >>>> which >>>>>>> would >>>>>>>>> be very helpful since users and admins will be able to present >>>>>>> locations >>>>>>>> in >>>>>>>>> an information rich map environment which will be interactive. >>>>>>>>> >>>>>>>>> Features >>>>>>>>> >>>>>>>>>> *Markers and popups* - Place markers anywhere on the map and >>>>>>> associate >>>>>>>>> popups with them. >>>>>>>>>> *Path between two points* - A path will be generated by the >>>>>>> application >>>>>>>>> linking two points of interest. >>>>>>>>>> *Location search* - Search any location on the map. >>>>>>>>>> *Filtered list maps* - Allow the user to search for a specific >>>>> kind >>>>>>> of >>>>>>>>> place (e.g. restaurants) and get a list of locations to choose >>>>> from. >>>>>>>>> Through the content available and binded to a location, the user >>>>> will >>>>>>> be >>>>>>>>> able to learn some aspects of the location. >>>>>>>>>> *Custom shapes* - Custom shapes can be used to highlight a >>>>> specific >>>>>>>> area >>>>>>>>> for representation. The content associated with these shapes can >>>>> give >>>>>>>>> useful information about the area. >>>>>>>>>> *Indoor maps* - Such maps will be able to describe the internal >>>>>>>> structure >>>>>>>>> or fair plan of a building or structure. They can be used to >>>> guide >>>>>>> users >>>>>>>> in >>>>>>>>> a big building and locate point of interests. >>>>>>>>>> *Maps on mobile* - Special design arrangements will be made for >>>>>>> easily >>>>>>>>> viewing of maps and availing all the features of the application >>>> on >>>>>>>> mobile >>>>>>>>> devices. >>>>>>>>>> *Custom map backgrounds* - Custom backgrounds will make the >>>>>>> environment >>>>>>>>> of interactive maps much suitable for a specific purpose >>>>>>>>> >>>>>>>>> If you have any features in mind that will make the Map >>>> Application >>>>>>>> better >>>>>>>>> please feel free to reply to this mail. >>>>>>>>> This is all for the summary of the project, if you want to have a >>>>>> more >>>>>>>>> deeper insight, please check out the full proposal. >>>>>>>>> >>>>>>>>> *Project Proposal: * >>>>>>>>> >>>> https://drive.google.com/open?id=14qXC7Oy2bPUASfVtSTIsNG1sPcfm5Ikr >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks for reading through the mail. I will be looking forward to >>>>>> your >>>>>>>>> guidance through this summer and your contributions to the >>>> project. >>>>>>>>> If you have any questions or suggestions, please feel free to >>>> reply >>>>>> to >>>>>>>> this >>>>>>>>> mail. >>>>>>>>> >>>>>>>>> Au revoir. :) >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Fawad Ali >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> >

Hi Caty, Fawad, all, [...]

* I've read again the GSOC project description. The main purpose of the application is to allow multiple people to create POIs and other shapes on the Maps. There is a note that the POIs will have additional information about the location. Some questions: ** can a POI be displayed in multiple Maps? For example: if we someone creates a 'Centre Pompidou' POI in a page, where adds information about the place, images, etc. Should we be able to display this POI in multiple maps (one that contains museums, while others contain modern architecture)?

I would say it's important that a point of interest or any other entity can be present in multiple maps indeed. A map is defined in particular by a query imho – I would suggest a Solr query as argued on the design page, what do you think? – which returns a set of elements. Then the user can refine this set at will using full-text search, facets or spatial search.

** in any case, the POI storage could be done in objects or in individual pages. We need to think about performance too. Pages will lots of objects can have performance issues, so storing as pages (that will contain objects for POI type) might be better?

Ideally that'd be great to support both options I would say. In terms of priority I would go for one object per page to start with. Typically, in the encyclopedia use case defined in the design page, having one object attached to each target page would be very convenient imho: it would ease the maintenance of information, both textual and geographical, related to each page. Supporting multiple objects per page could be quite useful as well. Imagine for instance that we want to represent the "Battle of the Somme" on a map. The content itself may refer to multiple locations (as on the Wikipedia article below and its static image map representation), so it could be handy to let the user input all these locations (points, areas, lines...) as objects attached to the "Battle of the Somme" page itself without the need to create individual pages for each location. There is no reason to hit a very large number of objects in this scenario though. What do you think? https://en.wikipedia.org/wiki/Battle_of_the_Somme

* Maps will also be pages, containing configuration (custom backgrounds), etc.

Indeed, a map page will consist of a map configuration imho. We need to define what is needed to configure a map, beside the query. The visual configuration is important as well and can be possibly complex, and other options could arise... Stéphane -- Stéphane Laurière XWiki – https://xwiki.com

Fawad, Thanks for your feedback. Regarding the data model: - Map: we clearly need a Map class :-). As discussed, it will hold the map configuration, and possible links to sub-configurations (such as the visual theme, to be discussed). Primarily, the map needs data, so it needs a field for storing a query that will make it possible to retrieve data. You certainly already found the Solr Query API documentation below, I suggest you give it a try and read the basic query principles, then we can set up dedicated examples together on real data in the next days. This brings us to the question of real data. We will quickly need sample data to work with, I think, I'm investigating how to download GeoJSON data from OpenStreetMap, which itself contains links to Wikidata or Wikipedia, this would allow us to grab some content and even images and to have a good sample data set to work with. I'll keep you posted about that. https://extensions.xwiki.org/xwiki/bin/view/Extension/Solr%20Search%20Query%... In parallel, you could start thinking about the design and implementation of the query endpoint that will return GeoJSON. Looking a bit into the code of "Main.SolrSearchMacros" could be useful I would say, I'll think about it as well. - Spatial entities : Point, Shape, Path, ...: I agree with you having one XClass for each is probably the way to go, but I would suggest we start just with "Point" and postpone the decision to a bit later if you agree, just to make sure we don't make wrong assumptions and introduce too much complexity (probably not, but to be discussed). Even the "icon" property might be too early at this stage imho, because in real world scenarios I believe it's more important to provide the ability to associate icons to facets key/value pairs than to individual items. It may be useful in the future, but we'll see, I would say. - Content: considering using content ids, or XPaths or XWiki DOM (XDOM) queries could be quite powerful. We don't want the users to maintain manually popup content, while they already have the burden to maintain the main content itself. Using content ids / queries would avoid duplicating content. This shares some concern with the Page Preview application, see links below. I don't have a clear answer yet, we need to discuss a bit further. But we could start with the first page paragraph for instance. https://dev.xwiki.org/xwiki/bin/view/Drafts/Page%20Preview%20Application https://xwiki.markmail.org/message/zhbaw7m3rsnbm26m?q=preview https://github.com/xwiki-contrib/application-page-preview I'll be off in the next couple of hours but I'll provide more feedback as soon as possible. Cheers Stéphane Fawad Ali:

Hi Stéphane and Ecaterina,

Thanks for the update to the design page. It feels much more detailed now imo. However it has left me confused with all the details. I was focused on a more straightforward approach but we need to be more detailed as I see it.

I would like to know how I should move forward with what I have already done. Considering the kind of structure Stephane suggests for the application, we will have to redo it completely because I do not think what I did so far is suitable for such requirements.

Let me first discuss the data model since that will be the basis of the application. We have the main entities as Map, Point, Shape, Path and Content. I think it's better if we have an XClass for each of them with properties that will highlight the available configurations for the entities. For example, for the Point class, we can have properties icon, location, content (may be an id from a content class object?).

Also, I am not much familiar with Solr or any of the query languages in XWiki since I was not going in that direction. I did try to look into Solr quite a bit but it would help me a lot if you could provide me an example.

And direction on how I move from here on out would also help a lot.

Best, Fawad

On Tue, May 28, 2019 at 6:14 PM Stéphane Laurière <[email protected] <mailto:[email protected]>> wrote:

Hi Caty, Fawad, all,

[...]

> * I've read again the GSOC project description. The main purpose of the > application is to allow multiple people to create POIs and other shapes on > the Maps. There is a note that the POIs will have additional information > about the location. > Some questions: > ** can a POI be displayed in multiple Maps? For example: if we someone > creates a 'Centre Pompidou' POI in a page, where adds information about the > place, images, etc. Should we be able to display this POI in multiple maps > (one that contains museums, while others contain modern architecture)?

I would say it's important that a point of interest or any other entity can be present in multiple maps indeed. A map is defined in particular by a query imho – I would suggest a Solr query as argued on the design page,  what do you think? – which returns a set of elements. Then the user can refine this set at will using full-text search, facets or spatial search.

> ** in any case, the POI storage could be done in objects or in individual > pages. We need to think about performance too. Pages will lots of objects > can have performance issues, so storing as pages (that will contain objects > for POI type) might be better?

Ideally that'd be great to support both options I would say.

In terms of priority I would go for one object per page to start with. Typically, in the encyclopedia use case defined in the design page, having one object attached to each target page would be very convenient imho: it would ease the maintenance of information, both textual and geographical, related to each page.

Supporting multiple objects per page could be quite useful as well. Imagine for instance that we want to represent the "Battle of the Somme" on a map. The content itself may refer to multiple locations (as on the Wikipedia article below and its static image map representation), so it could be handy to let the user input all these locations (points, areas, lines...) as objects attached to the "Battle of the Somme" page itself without the need to create individual pages for each location. There is no reason to hit a very large number of objects in this scenario though. What do you think?

https://en.wikipedia.org/wiki/Battle_of_the_Somme

> * Maps will also be pages, containing configuration (custom backgrounds), > etc.

Indeed, a map page will consist of a map configuration imho. We need to define what is needed to configure a map, beside the query. The visual configuration is important as well and can be possibly complex, and other options could arise...

Stéphane

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

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

What I will be doing now is create a Map class that can hold configuration properties. If these properties are filled then that data will be used while generating the map else some default configuration will be used. Maybe I will make a separate object for default configuration of the map? Then once I am able to generate a map with the map class I will add a query based property to the map which will hold the query to what the map will have. A macro (maybe some other option?) will be made to handle the data gotten from the query. As we are focusing on a Point for now, I will make the macro so that if a Point object is queried, I will get all the properties of that particular point and add it to the map. For now I will only be querying objects on the same page to reduce complexity at an early stage. Is this a good approach for now or am I in the wrong direction? I really think we should have a detailed video conference since that will get us all on the same page and will take minimum time. Best, Fawad On Tue, May 28, 2019 at 8:30 PM Fawad Ali <[email protected]> wrote:

Stéphane,

I will start off by learning Solr Search Query API and see how I can use it in this application.

One major concern is how we will be creating our maps. I introduced the idea of a map editor but now it seems that we will be using queries to generate our maps. What I have in mind after this is that the user will create an object of Map class and then associate a query with it but I don't know how we will get the relevant data for the map. For example if we want a point on the map, how would we identify that we need that point. Do we have all the relevant objects on a single page and then get all of them from that page to display those features on the map?

Can you give a reference to an application that is similar in structure to what we are striving for in this application? I can't help but feel like this will lead to something of a "Map Service" rather than a "Map Application". Sorry about all this confusion.

Maybe we can have a recorded video/audio conference as that will save us a lot of time discussing these things. WDYT?

Best, Fawad

On Tue, May 28, 2019 at 7:44 PM Stéphane Laurière <[email protected]> wrote:

...

Fawad,

Thanks for your feedback.

Regarding the data model:

- Map: we clearly need a Map class :-). As discussed, it will hold the map configuration, and possible links to sub-configurations (such as the visual theme, to be discussed). Primarily, the map needs data, so it needs a field for storing a query that will make it possible to retrieve data. You certainly already found the Solr Query API documentation below, I suggest you give it a try and read the basic query principles, then we can set up dedicated examples together on real data in the next days. This brings us to the question of real data. We will quickly need sample data to work with, I think, I'm investigating how to download GeoJSON data from OpenStreetMap, which itself contains links to Wikidata or Wikipedia, this would allow us to grab some content and even images and to have a good sample data set to work with. I'll keep you posted about that.

https://extensions.xwiki.org/xwiki/bin/view/Extension/Solr%20Search%20Query%...

In parallel, you could start thinking about the design and implementation of the query endpoint that will return GeoJSON. Looking a bit into the code of "Main.SolrSearchMacros" could be useful I would say, I'll think about it as well.

- Spatial entities : Point, Shape, Path, ...: I agree with you having one XClass for each is probably the way to go, but I would suggest we start just with "Point" and postpone the decision to a bit later if you agree, just to make sure we don't make wrong assumptions and introduce too much complexity (probably not, but to be discussed). Even the "icon" property might be too early at this stage imho, because in real world scenarios I believe it's more important to provide the ability to associate icons to facets key/value pairs than to individual items. It may be useful in the future, but we'll see, I would say.

- Content: considering using content ids, or XPaths or XWiki DOM (XDOM) queries could be quite powerful. We don't want the users to maintain manually popup content, while they already have the burden to maintain the main content itself. Using content ids / queries would avoid duplicating content. This shares some concern with the Page Preview application, see links below. I don't have a clear answer yet, we need to discuss a bit further. But we could start with the first page paragraph for instance.

https://dev.xwiki.org/xwiki/bin/view/Drafts/Page%20Preview%20Application https://xwiki.markmail.org/message/zhbaw7m3rsnbm26m?q=preview https://github.com/xwiki-contrib/application-page-preview

I'll be off in the next couple of hours but I'll provide more feedback as soon as possible.

Cheers

Stéphane

Fawad Ali:

...

Hi Stéphane and Ecaterina,

Thanks for the update to the design page. It feels much more detailed now imo. However it has left me confused with all the details. I was focused on a more straightforward approach but we need to be more detailed as I see it.

I would like to know how I should move forward with what I have already done. Considering the kind of structure Stephane suggests for the application, we will have to redo it completely because I do not think what I did so far is suitable for such requirements.

Let me first discuss the data model since that will be the basis of the application. We have the main entities as Map, Point, Shape, Path and Content. I think it's better if we have an XClass for each of them with properties that will highlight the available configurations for the entities. For example, for the Point class, we can have properties icon, location, content (may be an id from a content class object?).

Also, I am not much familiar with Solr or any of the query languages in XWiki since I was not going in that direction. I did try to look into Solr quite a bit but it would help me a lot if you could provide me an example.

And direction on how I move from here on out would also help a lot.

Best, Fawad

On Tue, May 28, 2019 at 6:14 PM Stéphane Laurière <[email protected] <mailto:[email protected]>> wrote:

Hi Caty, Fawad, all,

[...]

> * I've read again the GSOC project description. The main purpose of the > application is to allow multiple people to create POIs and other shapes on > the Maps. There is a note that the POIs will have additional information > about the location. > Some questions: > ** can a POI be displayed in multiple Maps? For example: if we someone > creates a 'Centre Pompidou' POI in a page, where adds information about the > place, images, etc. Should we be able to display this POI in multiple maps > (one that contains museums, while others contain modern architecture)?

I would say it's important that a point of interest or any other entity can be present in multiple maps indeed. A map is defined in particular by a query imho – I would suggest a Solr query as argued on the design page, what do you think? – which returns a set of elements. Then the user can refine this set at will using full-text search, facets or spatial search.

> ** in any case, the POI storage could be done in objects or in individual > pages. We need to think about performance too. Pages will lots of objects > can have performance issues, so storing as pages (that will contain objects > for POI type) might be better?

Ideally that'd be great to support both options I would say.

In terms of priority I would go for one object per page to start with. Typically, in the encyclopedia use case defined in the design page, having one object attached to each target page would be very convenient imho: it would ease the maintenance of information, both textual and geographical, related to each page.

Supporting multiple objects per page could be quite useful as well. Imagine for instance that we want to represent the "Battle of the Somme" on a map. The content itself may refer to multiple locations (as on the Wikipedia article below and its static image map representation), so it could be handy to let the user input all these locations (points, areas, lines...) as objects attached to the "Battle of the Somme" page itself without the need to create individual pages for each location. There is no reason to hit a very large number of objects in this scenario though. What do you think?

https://en.wikipedia.org/wiki/Battle_of_the_Somme

> * Maps will also be pages, containing configuration (custom backgrounds), > etc.

Indeed, a map page will consist of a map configuration imho. We need to define what is needed to configure a map, beside the query. The visual configuration is important as well and can be possibly complex, and other options could arise...

Stéphane

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

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

Fawad,

Hi, Hope all are doing well.

Extremely thanks for the information Ecaterina. It really helps. :)

I am trying to make filterable list maps but I am more or less stuck.

This is what I have done so far: [image: image.png]

So what I have in mind for this is that each marker will have a category and a custom popup. Then we can have custom marker image for each of the category or for each of the marker separately. I wanted to have forms directly inside the popup but that does not seem to be possible giving how popups in leaflet work.

I see at two distinct aspects there: - How to associate a visual marker to a category or possibly to any attribute, conceptually - Which user interface do we design and implement to help users define such associations Imho, we have first to agree on the global mechanism to configure markers, then we'll think about the most appropriate user interface. Introducing the concept of category is handy but I fear it could be quicly limited in real world scenarios, not sure. Take the encyclopedia use case, we have HLS at hand, here is a list of places referenced in HLS (by pure coincidence the end point is named "category" here, but the underlying mechanism is a Solr facet): https://hls-dhs-dss.ch/fr/search/category?f_hls.lexicofacet_string=1%2F00680.... Imagine we want to represent these places on a map, with one icon per top level facet: political entity, ecclesiastical entity, environmnent, archeologia, etc. How can we specify that at the data model level? One option would be to introduce a mapping that associates pairs of Solr facet key, value to icons in the map configuration. We could have a large text field for that in the map configuration, what do you think? Another option would be to define a class for individual mappings, not sure it's needed though, a global text field might be enough, at least to begin with. Obviously this question hinges on the more general one about the query language we use to specify a set of entities to be represented on a map. Regarding the user interface for configuring such associations, I have no clear proposal at this stage on my side, however I would suggest we validate the mechanism first, we implement it, and we consider making a visual configurator in a second step, what is your view on that? I agree it's not very handy to define such mappings as text, but on the other hand we gain in extensibility, and easing the configuration remains possible once the global use case is validated and accepted by real-world users (hopefully not far in future, in the frame of the GSoC itself if possible).

This is a little afar from what I observe in https://napoleon-sainte-helene.plan-interactif.com and I am unable to think of a better way to manage everything.

Sorry, I don't understand well what's the scope of the comparison. Are you referring to the marker display, or the filters, or to the way markers can be configured, and if so, how did you access the marker configuration? Cheers Stéphane

Stephane or Ecaterina, if you have a better approach and flow for this then please let me know. And Stephane, your help would be highly appreciable.

Thanks. Best, Fawad

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

Hi Stéphane, Ecaterina and all, Hope all of you are doing wonderful! So I am working on the new iteration for the Interactive Maps Application and have made some progress which I would like to share with all of you. As suggested by Stephane, the application is now being developed on a new architecture which emphasizes the use of Solr queries for gathering data to display on the map. The space has also been changed to "Maps" as suggested by Ecaterina. Link: https://github.com/9inpachi/interactive-maps-new I have not shifted the files to xwiki-contrib because I wanted an initial review if I am doing the right thing so I don't have to change the whole repo twice. I have been able to generate a map and the application is now able to handle basic queries to include points (markers) inside the map. I would like you to please give it a look and let me know if I am going in the right direction. :) Main application pages: - Maps.Code.Map.MapClass => The main map class - Maps.Code.Map.MapSheet => Map sheet that renders the map - Maps.Code.Map.WebHome => Simple form for creating a map object page - Maps.Code.Point.PointClass => Main class for a simple point (marker) - Maps.Code.Leaflet => Page where all the javascript and stylesheet extensions exist - Maps.Code.CommonMacros => Some common macros used throughout the application - Maps.MapTesting => Space that contains objects and maps for testing For adding a Point, create a simple page, add content to it and attach a PointClass object with a value to it. If you want to have a look at how the map is rendered, see the MapSheet and the relevant jsx (leaflet-main) code on the Leaflet page. I have attached some screenshots to show what the application does at this point. Best, Fawad On Wed, May 29, 2019 at 5:12 PM Fawad Ali <[email protected]> wrote:

Stéphane,

Thanks for this. It summarizes our discussions perfectly. :) It's actually great that we are on the same page now. I will provide you with updates soon.

Best, Fawad

On Wed, May 29, 2019 at 4:34 PM Stéphane Laurière <[email protected]> wrote:

...

Fawad, Caty, all,

A quick update following a video call I had with Fawad:

- The Solr API will be used to query the data to be displayed on the map, and the Solr facets to apply additional filters

- The data returned by the Solr API will be converted to GeoJSON. Later on we may consider creating a Solr service that returns (Geo)JSON directly rather than HTML, to be discussed.

Next steps:

- Creation of a basic Map class with a Solr query field

- Creation of a MapSheet that will render the map itself

- Creation of a Point class that will consist of one field storing the latitude and the longitude separated by a comma (later on, if needed, we will consider storing the latitude and the longitude in two distinct fields)

- Manual creation (or via the BatchImport application) of 1) a set of sample pages that will consist of: a title, some content, and a Point object attached to each page, 2) a Map object with a simple Solr query returning all pages with a Point object in a specific space.

- Conversion of the the results provided by Solr into GeoJSON so that the data can be consumed and displayed by Leaflet

Fawad, please don't hesitate to mention any complementary aspect that I may have forgotten or questions you may have.

Cheers

Stéphane

Hi all, Thanks for the detailed review, Stephane. I have made the changes you suggested with some next steps also done. Furthermore, I will make changes to the application space once we have confirmed response from Caty or other developers. I have started to work on the other next steps and will provide with updates soon. The original github repo is also updated, so future updates will be available at https://github.com/xwiki-contrib/application-interactive-maps . Thanks, Fawad On Mon, Jun 3, 2019 at 12:38 PM Stéphane Laurière <[email protected]> wrote:

Hi Fawad, Caty, all,

Good to know where you are, Fawad. You're on the right track indeed imho, we're in tune.

I'm sending you below some feedback (part of it is code review that could take place directly on GitHub, but I feel it easier to discuss about it all together on the list for now, let's see how it goes, I'm open to any suggestion).

== MapClass and MapTemplate ==

- Query field: I'd suggest we use a large string field because the queries could become more complex in the future

- I would consider putting the default values directly in the template, so that the user can know what they are when he creates a map, what do you think?

- What about using an integer rather than a long for the zoom level?

- You probably already have this in mind: this will be handy to create a MapTemplateProvider as well, for example as indicated on < https://extensions.xwiki.org/xwiki/bin/view/Extension/Administration+Applica...

...

== MapSheet ==

- Map creation: usually, class instances get created directly in the space of the application (see for instance the Diagram application), I would suggest we do the same here if that's ok with you, i.e. directly in the Map space, for maps and for points as well. As for test data: we will need to store test data indeed without the need to recreate it manually everytime, I'm adding an item about that in the "Next steps" section below.

- Currently, the sheet issues a call to com.xpn.xwiki.api.Object:getXWikiObject. This method requires programming rights. Most of the classes in package com.xpn.xwiki.api give access to their wrapped core object only to users with programming rights, since it allows to manipulate the data at a low level. I'm adding some links below that may help you understand this aspect (you may know them already). Another option (the one I favour) is to always have the xwiki-platform source code at hand in the IDE, so that one can check what the API does exactly. In an XWiki sheet, we typically don't want the programming right to be required, because sheets are meant to be customized by users, not necessarily by administrators. You will hence have to generate the target JSON without resorting to the wrapped BaseObject.

https://www.xwiki.org/xwiki/bin/view/Documentation/DevGuide/Scripting/

http://nexus.xwiki.org/nexus/service/local/repositories/public/archive/org/x...

- I'm wondering if it's necessary to generate a random id for the map container: couldn't we simply use the lower-case serialized map reference?

== CommonMacros ==

Yes, the "handleMapQuery" macro is in the right direction.

== Global code organization ==

- Currently the code uses one space per class. That's an option indeed, but it seems to me that the usual practice is more to group all classes and sheets directly in the "Code" space. See for instance the blog application: https://github.com/xwiki-contrib/application-blog/tree/master/application-bl.... What do you think Caty, all?

- We're currently using the "Maps" space. I know the plural was discussed for the app name already, I have no further comment about that. In existing XWiki applications, we use either the singular or the plural for the application space. For instance, the following apps use the singular: application-diagram, application-xpoll, application-meeting, batchimport, application-forum, application-flashmessages (plural in the application name, singular in the space name in this case). Other use plural everywhere: application-invoices, application-ideas. Question to Caty and to all: do we have guidelines for that? This is a minor issue but I have a slight preference for using the singular in the space name, since to me it refers primarily to the application itself, not necessarily to the location where the target instances will be created. Typically, maps could be created anywhere in the wiki. The map app code, though, will be stored in that space. Sorry for being picky, I just want to make sure we all agree on the final name before a potential refactoring becomes more complex.

== Next steps ==

You probably have several of the next steps if not all in mind already, I'm listing some of them below so that we make sure to converge and decide:

- Add a livetable listing all existing maps, in the "WebHome" page of the top level application space

- Display page titles in the popups

- Find a way to plug the query mechanism to the Main.SolrSearch and Main.SolrSearchMacros (so that we can then use facets). This can be a bit tricky, let us know if you need help of course, for this aspect or any other.

- Add a full-text input widget to the map that will issue Solr queries asynchronously to the map query service (example: the user inputs "archeologia" -> only pages matching that word will get returned, and only the corresponding points will show up on the map), which will return the documents matching the initial query completed by the added full-text constraint.

- Add a contextual paginated list of results.

- Add facet filters.

- Test data: for now, we have just a few points to test with, but in the near future we will need one or several rich data sets samples to test the application. I'm not sure whether we should put the data and the code to create it in the same repository as the application itself or if we should create a dedicated repository. Typically, I foresee some code that will fetch some data from Wikidata or OpenStreetMap and convert it to several hundreds or thousands of XWiki pages, which in turn will be consumed by a map. Example: the query below executed against the endpoint https://query.wikidata.org/ will return all the museums referenced in Wikidata with their name, their geographical coordinates and their country. We could grab the museum JSON representations and turn them into XWiki pages (I have some code for doing such operations in another context already, I will commit it soon). I'm wondering if we store the test data and code in the same repository (this can amount to hundreds of test pages), or in a distinct one. I'll send a separate question to the list about this aspect.

SELECT ?item ?itemLabel ?coord ?lon ?lat ?country ?countryLabel WHERE { ?item wdt:P17 ?country. ?item wdt:P31 wd:Q33506. # is a museum ?item p:P625 ?coordinate. ?coordinate ps:P625 ?coord. ?coordinate psv:P625 ?coordinate_node. ?coordinate_node wikibase:geoLongitude ?lon. ?coordinate_node wikibase:geoLatitude ?lat. SERVICE wikibase:label { bd:serviceParam wikibase:language "en". } }

- Regarding paths: I saw you mentioned them on #xwiki, that will be an important feature indeed but I feel like it's more important to make sure that we have a working prototype consisting of a map, a search input, a list and facets with points already, before adding more complex objects to the map, what do you think?

Cheers

Stéphane

Fawad Ali:

...

Hi Stéphane, Ecaterina and all, Hope all of you are doing wonderful!

So I am working on the new iteration for the Interactive Maps Application and have made some progress which I would like to share with all of you. As suggested by Stephane, the application is now being developed on a new architecture which emphasizes the use of Solr queries for gathering data to display on the map. The space has also been changed to "Maps" as suggested by Ecaterina.

Link: https://github.com/9inpachi/interactive-maps-new I have not shifted the files to xwiki-contrib because I wanted an initial review if I am doing the right thing so I don't have to change the whole repo twice.

I have been able to generate a map and the application is now able to handle basic queries to include points (markers) inside the map.

I would like you to please give it a look and let me know if I am going in the right direction. :)

Main application pages: - Maps.Code.Map.MapClass => The main map class - Maps.Code.Map.MapSheet => Map sheet that renders the map - Maps.Code.Map.WebHome => Simple form for creating a map object page - Maps.Code.Point.PointClass => Main class for a simple point (marker) - Maps.Code.Leaflet => Page where all the javascript and stylesheet extensions exist - Maps.Code.CommonMacros => Some common macros used throughout the application - Maps.MapTesting => Space that contains objects and maps for testing

For adding a Point, create a simple page, add content to it and attach a PointClass object with a value to it.

If you want to have a look at how the map is rendered, see the MapSheet and the relevant jsx (leaflet-main) code on the Leaflet page.

I have attached some screenshots to show what the application does at this point.

Best, Fawad

On Wed, May 29, 2019 at 5:12 PM Fawad Ali <[email protected] <mailto:[email protected]>> wrote:

Stéphane,

Thanks for this. It summarizes our discussions perfectly. :) It's actually great that we are on the same page now. I will provide you with updates soon.

Best, Fawad

On Wed, May 29, 2019 at 4:34 PM Stéphane Laurière < [email protected] <mailto:[email protected]>> wrote:

Fawad, Caty, all,

A quick update following a video call I had with Fawad:

- The Solr API will be used to query the data to be displayed on the map, and the Solr facets to apply additional filters

- The data returned by the Solr API will be converted to GeoJSON. Later on we may consider creating a Solr service that returns (Geo)JSON directly rather than HTML, to be discussed.

Next steps:

- Creation of a basic Map class with a Solr query field

- Creation of a MapSheet that will render the map itself

- Creation of a Point class that will consist of one field storing the latitude and the longitude separated by a comma (later on, if needed, we will consider storing the latitude and the longitude in two distinct fields)

- Manual creation (or via the BatchImport application) of 1) a set of sample pages that will consist of: a title, some content, and a Point object attached to each page, 2) a Map object with a simple Solr query returning all pages with a Point object in a specific space.

- Conversion of the the results provided by Solr into GeoJSON so that the data can be consumed and displayed by Leaflet

Fawad, please don't hesitate to mention any complementary aspect that I may have forgotten or questions you may have.

Cheers

Stéphane

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

Hi Stephane, Caty and all, Hope you are doing fine. I am glad you brought up the topic of custom marker icon. I am well aware of the issue. Actually there are two problems with custom markers. - The icon offset - The document attachment For the icon offset, when I tried to fix it initially it seemed that I can overcome the offset either by height or width which means that the offset still exists from a single side so I had that postponed since I thought solr query tasks take priority. For the attachment, for now I am getting the first attachment (0th index) from the Point page which is not very reliable. For example if we have images on the page, it could be that the marker takes one of the attachments even if the user did not want a custom icon or an image different from what the user wanted to choose is selected as the marker icon. What I have in mind is that we define categories for marker icons dynamically. We could make a separate dedicated page "MarkerIcons" and attach multiple images to it. Then these images could appear in a list as one of the properties in the Point object where we can choose the icon from. WDYT? Thanks, Fawad On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[email protected] wrote:

Fawad, Thanks for letting us know, I could install the new app version, I confirm that all the changes you added to the progress file (very handy) work for me, and the refactoring is ok. I noticed a minor issue that you're certainly aware of already: it seems there's a small offset between the custom marker position (with the Islamabad point) and the popup position.

Talk to you soon,

Stéphane

Fawad Ali:

...

Hi all,

Thanks for the detailed review, Stephane. I have made the changes you suggested with some next steps also done.

Furthermore, I will make changes to the application space once we have confirmed response from Caty or other developers. I have started to work on the other next steps and will provide with updates soon.

The original github repo is also updated, so future updates will be available at https://github.com/xwiki-contrib/application-interactive-maps .

Thanks, Fawad

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

Hi, Some notes: - We don't have guidelines regarding the singular / plural thing. I'm glad that on the new sources we don't have the Maps/Map anymore. I'm fine with Maps. In practice we have a mix of singular (like Diagram, Calendar, Meeting) and plural (like Ideas, Forums). I prefer the plural version, although in practice I think we have more with singular. There was a tentative old draft for having such guidelines https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines but we didn't worked on it for some time. - Regarding the new Git repository. Since you've committed the initial commits in issues, you should do a release with the initial version, and than just release a new version for the interactive-maps-new . It's normal in an application's development flow that changes happen, that's why versioning schemes are all about. - I still have the error I've mentioned before : Uncaught Error: Script error for "leaflet", needed by: leafletSearch http://requirejs.org/docs/errors.html#scripterror at F (require.min.js?r=1:7) at HTMLScriptElement.onScriptError (require.min.js?r=1:30) leaflet.css:1 Failed to load resource: the server responded with a status of 404 (Not Found) so I cannot actually test the build, since I don't see the maps. I have this both on Chrome and Firefox. Do I need to do something? Thanks, Caty On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[email protected]> wrote:

Also, I forgot to mention it before but we will need a better and more expressive way to show popups. We need something that can accomodate sufficient amount of text with a scroll if the information exceeds the page. I will prepare a mockup for this once I am done with some of the next steps.

And I think we should use the colortheme colors for our map controls and consequently for the popups. I will update you on that as well.

Best, Fawad

On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[email protected]> wrote:

...

Hi Stephane, Caty and all, Hope you are doing fine.

I am glad you brought up the topic of custom marker icon. I am well aware of the issue. Actually there are two problems with custom markers. - The icon offset - The document attachment

For the icon offset, when I tried to fix it initially it seemed that I can overcome the offset either by height or width which means that the offset still exists from a single side so I had that postponed since I thought solr query tasks take priority.

For the attachment, for now I am getting the first attachment (0th index) from the Point page which is not very reliable. For example if we have images on the page, it could be that the marker takes one of the attachments even if the user did not want a custom icon or an image different from what the user wanted to choose is selected as the marker icon.

What I have in mind is that we define categories for marker icons dynamically. We could make a separate dedicated page "MarkerIcons" and attach multiple images to it. Then these images could appear in a list as one of the properties in the Point object where we can choose the icon from. WDYT?

Thanks, Fawad

On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[email protected] wrote:

...

Fawad, Thanks for letting us know, I could install the new app version, I confirm that all the changes you added to the progress file (very handy) work for me, and the refactoring is ok. I noticed a minor issue that you're certainly aware of already: it seems there's a small offset between the custom marker position (with the Islamabad point) and the popup position.

Talk to you soon,

Stéphane

Fawad Ali:

...

Hi all,

Thanks for the detailed review, Stephane. I have made the changes you suggested with some next steps also done.

Furthermore, I will make changes to the application space once we have confirmed response from Caty or other developers. I have started to work on the other next steps and will provide with updates soon.

The original github repo is also updated, so future updates will be available at https://github.com/xwiki-contrib/application-interactive-maps.

Thanks, Fawad

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

I've used the latest build from https://github.com/9inpachi/interactive-maps-new and I have the error both on 11.4-rc-1 and some 11.4-snapshot. Thanks, Caty On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[email protected]> wrote:

Hi,

Caty, do you have the error with the latest git repo as well? Actually the leaflet-commons require leaflet but the functions are not actually called anywhere without the leaflet dependency used in require.

There is no error on my or Stephane side. I have the 11.3-rc version of XWiki. You can try Ctrl+F5 for a complete new load of the resources.

Best, Fawad

On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) <[email protected] wrote:

...

Hi,

Some notes: - We don't have guidelines regarding the singular / plural thing. I'm glad that on the new sources we don't have the Maps/Map anymore. I'm fine with Maps. In practice we have a mix of singular (like Diagram, Calendar, Meeting) and plural (like Ideas, Forums). I prefer the plural version, although in practice I think we have more with singular. There was a tentative old draft for having such guidelines https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines but we didn't worked on it for some time.

- Regarding the new Git repository. Since you've committed the initial commits in issues, you should do a release with the initial version, and than just release a new version for the interactive-maps-new . It's normal in an application's development flow that changes happen, that's why versioning schemes are all about.

- I still have the error I've mentioned before : Uncaught Error: Script error for "leaflet", needed by: leafletSearch http://requirejs.org/docs/errors.html#scripterror at F (require.min.js?r=1:7) at HTMLScriptElement.onScriptError (require.min.js?r=1:30)

leaflet.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)

so I cannot actually test the build, since I don't see the maps. I have this both on Chrome and Firefox. Do I need to do something?

Thanks, Caty

On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[email protected]> wrote:

...

Also, I forgot to mention it before but we will need a better and more expressive way to show popups. We need something that can accomodate sufficient amount of text with a scroll if the information exceeds the page. I will prepare a mockup for this once I am done with some of the next steps.

And I think we should use the colortheme colors for our map controls and consequently for the popups. I will update you on that as well.

Best, Fawad

On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[email protected]> wrote:

...

Hi Stephane, Caty and all, Hope you are doing fine.

I am glad you brought up the topic of custom marker icon. I am well aware of the issue. Actually there are two problems with custom markers. - The icon offset - The document attachment

For the icon offset, when I tried to fix it initially it seemed that I can overcome the offset either by height or width which means that the offset still exists from a single side so I had that postponed since I thought solr query tasks take priority.

For the attachment, for now I am getting the first attachment (0th index) from the Point page which is not very reliable. For example if we have images on the page, it could be that the marker takes one of the attachments even if the user did not want a custom icon or an image different from what the user wanted to choose is selected as the marker icon.

What I have in mind is that we define categories for marker icons dynamically. We could make a separate dedicated page "MarkerIcons" and attach multiple images to it. Then these images could appear in a list as one of the properties in the Point object where we can choose the icon from. WDYT?

Thanks, Fawad

On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[email protected] wrote:

...

Fawad, Thanks for letting us know, I could install the new app version, I confirm that all the changes you added to the progress file (very handy) work for me, and the refactoring is ok. I noticed a minor issue that you're certainly aware of already: it seems there's a small offset between the custom marker position (with the Islamabad point) and the popup position.

Talk to you soon,

Stéphane

Fawad Ali:

...

Hi all,

Thanks for the detailed review, Stephane. I have made the changes you suggested with some next steps also done.

Furthermore, I will make changes to the application space once we have confirmed response from Caty or other developers. I have started to work on the other next steps and will provide with updates soon.

The original github repo is also updated, so future updates will be available at https://github.com/xwiki-contrib/application-interactive-maps.

Thanks, Fawad

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

I just built and imported the application from my own repo ( https://github.com/9inpachi/interactive-maps-new) and everything seems fine. There was that error in the more earlier builds but it was fixed, may be some of the source files (especially Leaflet.xml) are old? Try building the source files anew with "mvn clean install". May be that will help. Thanks, Fawad On Wed, Jun 5, 2019, 10:37 PM Fawad Ali <[email protected] wrote:

We have shifted the repo to xwiki-contrib again. You may try that. I will also check my own repo for any errors ASAP.

Best, Fawad

On Wed, Jun 5, 2019, 10:35 PM Ecaterina Moraru (Valica) <[email protected] wrote:

...

I've used the latest build from https://github.com/9inpachi/interactive-maps-new and I have the error both on 11.4-rc-1 and some 11.4-snapshot.

Thanks, Caty

On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[email protected]> wrote:

...

Hi,

Caty, do you have the error with the latest git repo as well? Actually the leaflet-commons require leaflet but the functions are not actually called anywhere without the leaflet dependency used in require.

There is no error on my or Stephane side. I have the 11.3-rc version of XWiki. You can try Ctrl+F5 for a complete new load of the resources.

Best, Fawad

On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) < [email protected] wrote:

...

Hi,

Some notes: - We don't have guidelines regarding the singular / plural thing. I'm glad that on the new sources we don't have the Maps/Map anymore. I'm fine with Maps. In practice we have a mix of singular (like Diagram, Calendar, Meeting) and plural (like Ideas, Forums). I prefer the plural version, although in practice I think we have more with singular. There was a tentative old draft for having such guidelines https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines but we didn't worked on it for some time.

- Regarding the new Git repository. Since you've committed the initial commits in issues, you should do a release with the initial version, and than just release a new version for the interactive-maps-new . It's normal in an application's development flow that changes happen, that's why versioning schemes are all about.

- I still have the error I've mentioned before : Uncaught Error: Script error for "leaflet", needed by: leafletSearch http://requirejs.org/docs/errors.html#scripterror at F (require.min.js?r=1:7) at HTMLScriptElement.onScriptError (require.min.js?r=1:30)

leaflet.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)

so I cannot actually test the build, since I don't see the maps. I have this both on Chrome and Firefox. Do I need to do something?

Thanks, Caty

On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[email protected]> wrote:

...

Also, I forgot to mention it before but we will need a better and more expressive way to show popups. We need something that can accomodate sufficient amount of text with a scroll if the information exceeds the page. I will prepare a mockup for this once I am done with some of the next steps.

And I think we should use the colortheme colors for our map controls and consequently for the popups. I will update you on that as well.

Best, Fawad

On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[email protected]> wrote:

...

Hi Stephane, Caty and all, Hope you are doing fine.

I am glad you brought up the topic of custom marker icon. I am well aware of the issue. Actually there are two problems with custom markers. - The icon offset - The document attachment

For the icon offset, when I tried to fix it initially it seemed that I can overcome the offset either by height or width which means that the offset still exists from a single side so I had that postponed since I thought solr query tasks take priority.

For the attachment, for now I am getting the first attachment (0th index) from the Point page which is not very reliable. For example if we have images on the page, it could be that the marker takes one of the attachments even if the user did not want a custom icon or an image different from what the user wanted to choose is selected as the marker icon.

What I have in mind is that we define categories for marker icons dynamically. We could make a separate dedicated page "MarkerIcons" and attach multiple images to it. Then these images could appear in a list as one of the properties in the Point object where we can choose the icon from. WDYT?

Thanks, Fawad

On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière <[email protected] wrote:

> Fawad, Thanks for letting us know, I could install the new app > version, I confirm that all the changes you added to the progress file > (very handy) work for me, and the refactoring is ok. I noticed a minor > issue that you're certainly aware of already: it seems there's a small > offset between the custom marker position (with the Islamabad point) and > the popup position. > > Talk to you soon, > > Stéphane > > > Fawad Ali: > > Hi all, > > > > Thanks for the detailed review, Stephane. I have made the changes > you suggested with some next steps also done. > > > > Furthermore, I will make changes to the application space once we > have confirmed response from Caty or other developers. > > I have started to work on the other next steps and will provide > with updates soon. > > > > The original github repo is also updated, so future updates will > be available at > https://github.com/xwiki-contrib/application-interactive-maps. > > > > Thanks, > > Fawad > > > -- > Stéphane Laurière > XWiki – https://xwiki.com > > >

Hi Caty, The last thing to be wary of is to have the Leaflet dependency installed. If I remove my Leaflet webjar, I get this set of errors. GET http://ginpachi-pc:8080/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.css net::ERR_ABORTED 404 (Not Found) require.min.js?r=1:34 GET http://ginpachi-pc:8080/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.js?r=1 net::ERR_ABORTED 404 (Not Found) require.min.js?r=1:7 Uncaught Error: Script error for "leaflet", needed by: leafletSearch http://requirejs.org/docs/errors.html#scripterror at F (require.min.js?r=1:7) at HTMLScriptElement.onScriptError (require.min.js?r=1:30) I think Its the same problem your side. For installing Leaflet, search for Map Macro in extensions, from its dependencies tab in details go to Leaflet and install it. That ought to work. :) Best, Fawad On Thu, Jun 6, 2019 at 2:24 PM Ecaterina Moraru (Valica) <[email protected]> wrote:

Hi Fawad,

I still have the issue: no maps loaded, leaflet.css error in console. Tested with the most recent snapshot of 11.5 and with the build from https://github.com/xwiki-contrib/application-interactive-maps I have the same problem with Firefox, Chrome, Safari and Opera. I'm on Mac. https://up1.xwikisas.com/#mXONZtF2qcMeftvnyJOSjw The script from “ http://localhost:8084/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.js?r=1” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.

Also Maps.MapTesting.Points.Islamabad.WebHome page seems to have error when importing (with the "Replace the page history with the history from the package" option) https://up1.xwikisas.com/#ag8AIsPHgcFYqVod2RMJQQ

Thanks, Caty

On Wed, Jun 5, 2019 at 8:50 PM Fawad Ali <[email protected]> wrote:

...

I just built and imported the application from my own repo ( https://github.com/9inpachi/interactive-maps-new) and everything seems fine.

There was that error in the more earlier builds but it was fixed, may be some of the source files (especially Leaflet.xml) are old? Try building the source files anew with "mvn clean install". May be that will help.

Thanks, Fawad

On Wed, Jun 5, 2019, 10:37 PM Fawad Ali <[email protected] wrote:

...

We have shifted the repo to xwiki-contrib again. You may try that. I will also check my own repo for any errors ASAP.

Best, Fawad

On Wed, Jun 5, 2019, 10:35 PM Ecaterina Moraru (Valica) < [email protected] wrote:

...

I've used the latest build from https://github.com/9inpachi/interactive-maps-new and I have the error both on 11.4-rc-1 and some 11.4-snapshot.

Thanks, Caty

On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[email protected]> wrote:

...

Hi,

Caty, do you have the error with the latest git repo as well? Actually the leaflet-commons require leaflet but the functions are not actually called anywhere without the leaflet dependency used in require.

There is no error on my or Stephane side. I have the 11.3-rc version of XWiki. You can try Ctrl+F5 for a complete new load of the resources.

Best, Fawad

On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) < [email protected] wrote:

...

Hi,

Some notes: - We don't have guidelines regarding the singular / plural thing. I'm glad that on the new sources we don't have the Maps/Map anymore. I'm fine with Maps. In practice we have a mix of singular (like Diagram, Calendar, Meeting) and plural (like Ideas, Forums). I prefer the plural version, although in practice I think we have more with singular. There was a tentative old draft for having such guidelines https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines but we didn't worked on it for some time.

- Regarding the new Git repository. Since you've committed the initial commits in issues, you should do a release with the initial version, and than just release a new version for the interactive-maps-new . It's normal in an application's development flow that changes happen, that's why versioning schemes are all about.

- I still have the error I've mentioned before : Uncaught Error: Script error for "leaflet", needed by: leafletSearch http://requirejs.org/docs/errors.html#scripterror at F (require.min.js?r=1:7) at HTMLScriptElement.onScriptError (require.min.js?r=1:30)

leaflet.css:1 Failed to load resource: the server responded with a status of 404 (Not Found)

so I cannot actually test the build, since I don't see the maps. I have this both on Chrome and Firefox. Do I need to do something?

Thanks, Caty

On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[email protected]> wrote:

> Also, I forgot to mention it before but we will need a better and > more expressive way to show popups. We need something that can accomodate > sufficient amount of text with a scroll if the information exceeds the page. > I will prepare a mockup for this once I am done with some of the > next steps. > > And I think we should use the colortheme colors for our map controls > and consequently for the popups. I will update you on that as well. > > Best, > Fawad > > > On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[email protected]> > wrote: > >> Hi Stephane, Caty and all, >> Hope you are doing fine. >> >> I am glad you brought up the topic of custom marker icon. I am well >> aware of the issue. Actually there are two problems with custom markers. >> - The icon offset >> - The document attachment >> >> For the icon offset, when I tried to fix it initially it seemed >> that I can overcome the offset either by height or width which means that >> the offset still exists from a single side so I had that postponed since I >> thought solr query tasks take priority. >> >> For the attachment, for now I am getting the first attachment (0th >> index) from the Point page which is not very reliable. For example if we >> have images on the page, it could be that the marker takes one of the >> attachments even if the user did not want a custom icon or an image >> different from what the user wanted to choose is selected as the marker >> icon. >> >> What I have in mind is that we define categories for marker icons >> dynamically. >> We could make a separate dedicated page "MarkerIcons" and attach >> multiple images to it. Then these images could appear in a list as one of >> the properties in the Point object where we can choose the icon from. WDYT? >> >> Thanks, >> Fawad >> >> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière < >> [email protected] wrote: >> >>> Fawad, Thanks for letting us know, I could install the new app >>> version, I confirm that all the changes you added to the progress file >>> (very handy) work for me, and the refactoring is ok. I noticed a minor >>> issue that you're certainly aware of already: it seems there's a small >>> offset between the custom marker position (with the Islamabad point) and >>> the popup position. >>> >>> Talk to you soon, >>> >>> Stéphane >>> >>> >>> Fawad Ali: >>> > Hi all, >>> > >>> > Thanks for the detailed review, Stephane. I have made the >>> changes you suggested with some next steps also done. >>> > >>> > Furthermore, I will make changes to the application space once >>> we have confirmed response from Caty or other developers. >>> > I have started to work on the other next steps and will provide >>> with updates soon. >>> > >>> > The original github repo is also updated, so future updates will >>> be available at >>> https://github.com/xwiki-contrib/application-interactive-maps. >>> > >>> > Thanks, >>> > Fawad >>> >>> >>> -- >>> Stéphane Laurière >>> XWiki – https://xwiki.com >>> >>> >>>

Hi all, Hope you all are doing wonderfully. We still have the issue for the facets rendering but its up on the forum, so I think we will have some fixes for it in due time (thanks to Stephane). In the meantime, I will try making the facets more specific to the map. For now I am considering the following options for facets: - Tags - Search field (searches inside map item pages) - Map item type (PointClass for now) - Map item icon (?) - Map item space I will need some suggestions on which other options should be included. Next, I will - Be working on making a dedicated space for popups inside or besides the map. Something similar to https://abc.gogocarto.fr - Make use of theme styles and colors for the map itself and the items inside - Be making the query search asynchronous Also, I will be working part time for the next week and I have exams the week after that. So I would like to let you know that I would not be available for the exams period for the most part. :( I will try to finish most of the work and get the application in a stable state by then. :) Ecaterina also mentioned that we release the application, I propose we do that next week as soon as the facets are in a stable state. Thanks, Fawad On Thu, Jun 6, 2019 at 6:42 PM Ecaterina Moraru (Valica) <[email protected]> wrote:

That most likely is the problem, since I've just imported the XAR, no real install. I will try like that, thanks for helping.

Caty

On Thu, Jun 6, 2019 at 1:03 PM Fawad Ali <[email protected]> wrote:

...

Hi Caty,

The last thing to be wary of is to have the Leaflet dependency installed. If I remove my Leaflet webjar, I get this set of errors.

GET http://ginpachi-pc:8080/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.css net::ERR_ABORTED 404 (Not Found) require.min.js?r=1:34 GET http://ginpachi-pc:8080/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.js?r=1 net::ERR_ABORTED 404 (Not Found) require.min.js?r=1:7 Uncaught Error: Script error for "leaflet", needed by: leafletSearch http://requirejs.org/docs/errors.html#scripterror at F (require.min.js?r=1:7) at HTMLScriptElement.onScriptError (require.min.js?r=1:30)

I think Its the same problem your side. For installing Leaflet, search for Map Macro in extensions, from its dependencies tab in details go to Leaflet and install it. That ought to work. :)

Best, Fawad

On Thu, Jun 6, 2019 at 2:24 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi Fawad,

I still have the issue: no maps loaded, leaflet.css error in console. Tested with the most recent snapshot of 11.5 and with the build from https://github.com/xwiki-contrib/application-interactive-maps I have the same problem with Firefox, Chrome, Safari and Opera. I'm on Mac. https://up1.xwikisas.com/#mXONZtF2qcMeftvnyJOSjw The script from “ http://localhost:8084/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.js?r=1” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.

Also Maps.MapTesting.Points.Islamabad.WebHome page seems to have error when importing (with the "Replace the page history with the history from the package" option) https://up1.xwikisas.com/#ag8AIsPHgcFYqVod2RMJQQ

Thanks, Caty

On Wed, Jun 5, 2019 at 8:50 PM Fawad Ali <[email protected]> wrote:

...

I just built and imported the application from my own repo ( https://github.com/9inpachi/interactive-maps-new) and everything seems fine.

There was that error in the more earlier builds but it was fixed, may be some of the source files (especially Leaflet.xml) are old? Try building the source files anew with "mvn clean install". May be that will help.

Thanks, Fawad

On Wed, Jun 5, 2019, 10:37 PM Fawad Ali <[email protected] wrote:

...

We have shifted the repo to xwiki-contrib again. You may try that. I will also check my own repo for any errors ASAP.

Best, Fawad

On Wed, Jun 5, 2019, 10:35 PM Ecaterina Moraru (Valica) < [email protected] wrote:

...

I've used the latest build from https://github.com/9inpachi/interactive-maps-new and I have the error both on 11.4-rc-1 and some 11.4-snapshot.

Thanks, Caty

On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[email protected]> wrote:

> Hi, > > Caty, do you have the error with the latest git repo as well? > Actually the leaflet-commons require leaflet but the functions are > not actually called anywhere without the leaflet dependency used in require. > > There is no error on my or Stephane side. > I have the 11.3-rc version of XWiki. > You can try Ctrl+F5 for a complete new load of the resources. > > Best, > Fawad > > On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) < > [email protected] wrote: > >> Hi, >> >> Some notes: >> - We don't have guidelines regarding the singular / plural thing. >> I'm glad that on the new sources we don't have the Maps/Map anymore. I'm >> fine with Maps. In practice we have a mix of singular (like Diagram, >> Calendar, Meeting) and plural (like Ideas, Forums). I prefer the plural >> version, although in practice I think we have more with singular. There was >> a tentative old draft for having such guidelines >> https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines >> but we didn't worked on it for some time. >> >> - Regarding the new Git repository. Since you've committed the >> initial commits in issues, you should do a release with the initial >> version, and than just release a new version for the interactive-maps-new . >> It's normal in an application's development flow that changes happen, >> that's why versioning schemes are all about. >> >> - I still have the error I've mentioned before : >> Uncaught Error: Script error for "leaflet", needed by: leafletSearch >> http://requirejs.org/docs/errors.html#scripterror >> at F (require.min.js?r=1:7) >> at HTMLScriptElement.onScriptError (require.min.js?r=1:30) >> >> leaflet.css:1 Failed to load resource: the server responded with a >> status of 404 (Not Found) >> >> so I cannot actually test the build, since I don't see the maps. I >> have this both on Chrome and Firefox. Do I need to do something? >> >> Thanks, >> Caty >> >> On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[email protected]> >> wrote: >> >>> Also, I forgot to mention it before but we will need a better and >>> more expressive way to show popups. We need something that can accomodate >>> sufficient amount of text with a scroll if the information exceeds the page. >>> I will prepare a mockup for this once I am done with some of the >>> next steps. >>> >>> And I think we should use the colortheme colors for our map >>> controls and consequently for the popups. I will update you on that as well. >>> >>> Best, >>> Fawad >>> >>> >>> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali <[email protected]> >>> wrote: >>> >>>> Hi Stephane, Caty and all, >>>> Hope you are doing fine. >>>> >>>> I am glad you brought up the topic of custom marker icon. I am >>>> well aware of the issue. Actually there are two problems with custom >>>> markers. >>>> - The icon offset >>>> - The document attachment >>>> >>>> For the icon offset, when I tried to fix it initially it seemed >>>> that I can overcome the offset either by height or width which means that >>>> the offset still exists from a single side so I had that postponed since I >>>> thought solr query tasks take priority. >>>> >>>> For the attachment, for now I am getting the first attachment >>>> (0th index) from the Point page which is not very reliable. For example if >>>> we have images on the page, it could be that the marker takes one of the >>>> attachments even if the user did not want a custom icon or an image >>>> different from what the user wanted to choose is selected as the marker >>>> icon. >>>> >>>> What I have in mind is that we define categories for marker icons >>>> dynamically. >>>> We could make a separate dedicated page "MarkerIcons" and attach >>>> multiple images to it. Then these images could appear in a list as one of >>>> the properties in the Point object where we can choose the icon from. WDYT? >>>> >>>> Thanks, >>>> Fawad >>>> >>>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière < >>>> [email protected] wrote: >>>> >>>>> Fawad, Thanks for letting us know, I could install the new app >>>>> version, I confirm that all the changes you added to the progress file >>>>> (very handy) work for me, and the refactoring is ok. I noticed a minor >>>>> issue that you're certainly aware of already: it seems there's a small >>>>> offset between the custom marker position (with the Islamabad point) and >>>>> the popup position. >>>>> >>>>> Talk to you soon, >>>>> >>>>> Stéphane >>>>> >>>>> >>>>> Fawad Ali: >>>>> > Hi all, >>>>> > >>>>> > Thanks for the detailed review, Stephane. I have made the >>>>> changes you suggested with some next steps also done. >>>>> > >>>>> > Furthermore, I will make changes to the application space once >>>>> we have confirmed response from Caty or other developers. >>>>> > I have started to work on the other next steps and will >>>>> provide with updates soon. >>>>> > >>>>> > The original github repo is also updated, so future updates >>>>> will be available at >>>>> https://github.com/xwiki-contrib/application-interactive-maps. >>>>> > >>>>> > Thanks, >>>>> > Fawad >>>>> >>>>> >>>>> -- >>>>> Stéphane Laurière >>>>> XWiki – https://xwiki.com >>>>> >>>>> >>>>>

Hi Caty, Thanks for the review.

Maps/MapTesting/Maps/TestMap - I find it strange that the Maps space is duplicated

This space exists only for testing. It won't be there for the real application. I named them so that its easier to know which type of object pages are located in them (for myself). MapTesting, Maps, Points - spaces don't have homepages. The users will

navigate to them, since they are present in breadcrumb. So what is the plan? Simpler paths? or create Homepages for these types of entry?

Since we are in the beta stage now, the whole MapTesting space exists for testing for developers. It would not be there once we have a stable version ready for release. Lots of pages that are not hidden. All technical pages needs to be

hidden.

Again, these pages are not technical and exist only for testing purposes. A bit confusing that there are 2 search boxes for the maps, see

https://up1.xwikisas.com/#XngcOAZexsKE4DryH2i6zA

Yes, thanks for pointing out. We need to move the search function directly inside the map. I will look into it once I am done with the facets. For the search input, its in extremely beta stage. I am still trying to figure out the macros I have borrowed from SolrSearchMacros. So it will take time for me to make a more stable version of the facets. I hope I can do that in due time. :) Regarding the facets, we need some more user friendly translations and

customizations for this kind of UI, see https://up1.xwikisas.com/#TYj_9oLn84Mfp87VnwNgkw

As discussed earlier with Stephane, we are still having issues using the normal $facetDisplayer so we are using a workaround for testing purposes that's why it looks like this. More precisely, we are using the #displaySearchFacetValues($facetValues) macro for now. Best, Fawad On Fri, Jun 7, 2019 at 5:18 PM Ecaterina Moraru (Valica) <[email protected]> wrote:

Hi,

On Fri, Jun 7, 2019 at 2:01 PM Fawad Ali <[email protected]> wrote:

...

Hi all, Hope you all are doing wonderfully.

We still have the issue for the facets rendering but its up on the forum, so I think we will have some fixes for it in due time (thanks to Stephane). In the meantime, I will try making the facets more specific to the map. For now I am considering the following options for facets: - Tags - Search field (searches inside map item pages) - Map item type (PointClass for now) - Map item icon (?) - Map item space I will need some suggestions on which other options should be included.

Next, I will - Be working on making a dedicated space for popups inside or besides the map. Something similar to https://abc.gogocarto.fr - Make use of theme styles and colors for the map itself and the items inside - Be making the query search asynchronous

Also, I will be working part time for the next week and I have exams the week after that. So I would like to let you know that I would not be available for the exams period for the most part. :( I will try to finish most of the work and get the application in a stable state by then. :) Ecaterina also mentioned that we release the application, I propose we do that next week as soon as the facets are in a stable state.

That would be great in order for people to faster install it and test it. You could also request feedback on the forum if you want. When releasing you also need to write the documentation for the existing features, mentioning how to use them, etc. + list the fixed issues.

I managed to get the maps working. Thanks for your help. Some comments on the current state: - Maps/MapTesting/Maps/TestMap - I find it strange that the Maps space is duplicated - MapTesting, Maps, Points - spaces don't have homepages. The users will navigate to them, since they are present in breadcrumb. So what is the plan? Simpler paths? or create Homepages for these types of entry? - Lots of pages that are not hidden. All technical pages needs to be hidden. - A bit confusing that there are 2 search boxes for the maps, see https://up1.xwikisas.com/#XngcOAZexsKE4DryH2i6zA - The Search input is not really working. It kind of works (with a strange reload effect) for queries like "Paris" or "Moscow", but if you enter anything else it defaults on Paris. If that search is supposed to filter only the existing points than the placeholder should state that somehow + treat the non existing point with a "No point of interest found" or something. Also when it doesn't find the location, the search facets area is empty, so kind of hard for an user to recover it's track. - Regarding the facets, we need some more user friendly translations and customizations for this kind of UI, see https://up1.xwikisas.com/#TYj_9oLn84Mfp87VnwNgkw

Thanks, Caty

...

Thanks, Fawad

On Thu, Jun 6, 2019 at 6:42 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

...

That most likely is the problem, since I've just imported the XAR, no real install. I will try like that, thanks for helping.

Caty

On Thu, Jun 6, 2019 at 1:03 PM Fawad Ali <[email protected]> wrote:

...

Hi Caty,

The last thing to be wary of is to have the Leaflet dependency installed. If I remove my Leaflet webjar, I get this set of errors.

GET http://ginpachi-pc:8080/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.css net::ERR_ABORTED 404 (Not Found) require.min.js?r=1:34 GET http://ginpachi-pc:8080/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.js?r=1 net::ERR_ABORTED 404 (Not Found) require.min.js?r=1:7 Uncaught Error: Script error for "leaflet", needed by: leafletSearch http://requirejs.org/docs/errors.html#scripterror at F (require.min.js?r=1:7) at HTMLScriptElement.onScriptError (require.min.js?r=1:30)

I think Its the same problem your side. For installing Leaflet, search for Map Macro in extensions, from its dependencies tab in details go to Leaflet and install it. That ought to work. :)

Best, Fawad

On Thu, Jun 6, 2019 at 2:24 PM Ecaterina Moraru (Valica) < [email protected]> wrote:

...

Hi Fawad,

I still have the issue: no maps loaded, leaflet.css error in console. Tested with the most recent snapshot of 11.5 and with the build from https://github.com/xwiki-contrib/application-interactive-maps I have the same problem with Firefox, Chrome, Safari and Opera. I'm on Mac. https://up1.xwikisas.com/#mXONZtF2qcMeftvnyJOSjw The script from “ http://localhost:8084/xwiki/webjars/wiki%3Axwiki/leaflet/leaflet.js?r=1” was loaded even though its MIME type (“text/html”) is not a valid JavaScript MIME type.

Also Maps.MapTesting.Points.Islamabad.WebHome page seems to have error when importing (with the "Replace the page history with the history from the package" option) https://up1.xwikisas.com/#ag8AIsPHgcFYqVod2RMJQQ

Thanks, Caty

On Wed, Jun 5, 2019 at 8:50 PM Fawad Ali <[email protected]> wrote:

...

I just built and imported the application from my own repo ( https://github.com/9inpachi/interactive-maps-new) and everything seems fine.

There was that error in the more earlier builds but it was fixed, may be some of the source files (especially Leaflet.xml) are old? Try building the source files anew with "mvn clean install". May be that will help.

Thanks, Fawad

On Wed, Jun 5, 2019, 10:37 PM Fawad Ali <[email protected] wrote:

> We have shifted the repo to xwiki-contrib again. You may try that. I > will also check my own repo for any errors ASAP. > > Best, > Fawad > > On Wed, Jun 5, 2019, 10:35 PM Ecaterina Moraru (Valica) < > [email protected] wrote: > >> I've used the latest build from >> https://github.com/9inpachi/interactive-maps-new >> and I have the error both on 11.4-rc-1 and some 11.4-snapshot. >> >> Thanks, >> Caty >> >> On Wed, Jun 5, 2019 at 8:30 PM Fawad Ali <[email protected]> >> wrote: >> >>> Hi, >>> >>> Caty, do you have the error with the latest git repo as well? >>> Actually the leaflet-commons require leaflet but the functions are >>> not actually called anywhere without the leaflet dependency used in require. >>> >>> There is no error on my or Stephane side. >>> I have the 11.3-rc version of XWiki. >>> You can try Ctrl+F5 for a complete new load of the resources. >>> >>> Best, >>> Fawad >>> >>> On Wed, Jun 5, 2019, 10:22 PM Ecaterina Moraru (Valica) < >>> [email protected] wrote: >>> >>>> Hi, >>>> >>>> Some notes: >>>> - We don't have guidelines regarding the singular / plural thing. >>>> I'm glad that on the new sources we don't have the Maps/Map anymore. I'm >>>> fine with Maps. In practice we have a mix of singular (like Diagram, >>>> Calendar, Meeting) and plural (like Ideas, Forums). I prefer the plural >>>> version, although in practice I think we have more with singular. There was >>>> a tentative old draft for having such guidelines >>>> https://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationGuidelines >>>> but we didn't worked on it for some time. >>>> >>>> - Regarding the new Git repository. Since you've committed the >>>> initial commits in issues, you should do a release with the initial >>>> version, and than just release a new version for the interactive-maps-new . >>>> It's normal in an application's development flow that changes happen, >>>> that's why versioning schemes are all about. >>>> >>>> - I still have the error I've mentioned before : >>>> Uncaught Error: Script error for "leaflet", needed by: >>>> leafletSearch >>>> http://requirejs.org/docs/errors.html#scripterror >>>> at F (require.min.js?r=1:7) >>>> at HTMLScriptElement.onScriptError (require.min.js?r=1:30) >>>> >>>> leaflet.css:1 Failed to load resource: the server responded with >>>> a status of 404 (Not Found) >>>> >>>> so I cannot actually test the build, since I don't see the maps. >>>> I have this both on Chrome and Firefox. Do I need to do something? >>>> >>>> Thanks, >>>> Caty >>>> >>>> On Tue, Jun 4, 2019 at 2:31 PM Fawad Ali <[email protected]> >>>> wrote: >>>> >>>>> Also, I forgot to mention it before but we will need a better >>>>> and more expressive way to show popups. We need something that can >>>>> accomodate sufficient amount of text with a scroll if the information >>>>> exceeds the page. >>>>> I will prepare a mockup for this once I am done with some of the >>>>> next steps. >>>>> >>>>> And I think we should use the colortheme colors for our map >>>>> controls and consequently for the popups. I will update you on that as well. >>>>> >>>>> Best, >>>>> Fawad >>>>> >>>>> >>>>> On Tue, Jun 4, 2019 at 3:31 PM Fawad Ali < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Stephane, Caty and all, >>>>>> Hope you are doing fine. >>>>>> >>>>>> I am glad you brought up the topic of custom marker icon. I am >>>>>> well aware of the issue. Actually there are two problems with custom >>>>>> markers. >>>>>> - The icon offset >>>>>> - The document attachment >>>>>> >>>>>> For the icon offset, when I tried to fix it initially it seemed >>>>>> that I can overcome the offset either by height or width which means that >>>>>> the offset still exists from a single side so I had that postponed since I >>>>>> thought solr query tasks take priority. >>>>>> >>>>>> For the attachment, for now I am getting the first attachment >>>>>> (0th index) from the Point page which is not very reliable. For example if >>>>>> we have images on the page, it could be that the marker takes one of the >>>>>> attachments even if the user did not want a custom icon or an image >>>>>> different from what the user wanted to choose is selected as the marker >>>>>> icon. >>>>>> >>>>>> What I have in mind is that we define categories for marker >>>>>> icons dynamically. >>>>>> We could make a separate dedicated page "MarkerIcons" and >>>>>> attach multiple images to it. Then these images could appear in a list as >>>>>> one of the properties in the Point object where we can choose the icon >>>>>> from. WDYT? >>>>>> >>>>>> Thanks, >>>>>> Fawad >>>>>> >>>>>> On Tue, Jun 4, 2019, 11:31 AM Stéphane Laurière < >>>>>> [email protected] wrote: >>>>>> >>>>>>> Fawad, Thanks for letting us know, I could install the new app >>>>>>> version, I confirm that all the changes you added to the progress file >>>>>>> (very handy) work for me, and the refactoring is ok. I noticed a minor >>>>>>> issue that you're certainly aware of already: it seems there's a small >>>>>>> offset between the custom marker position (with the Islamabad point) and >>>>>>> the popup position. >>>>>>> >>>>>>> Talk to you soon, >>>>>>> >>>>>>> Stéphane >>>>>>> >>>>>>> >>>>>>> Fawad Ali: >>>>>>> > Hi all, >>>>>>> > >>>>>>> > Thanks for the detailed review, Stephane. I have made the >>>>>>> changes you suggested with some next steps also done. >>>>>>> > >>>>>>> > Furthermore, I will make changes to the application space >>>>>>> once we have confirmed response from Caty or other developers. >>>>>>> > I have started to work on the other next steps and will >>>>>>> provide with updates soon. >>>>>>> > >>>>>>> > The original github repo is also updated, so future updates >>>>>>> will be available at >>>>>>> https://github.com/xwiki-contrib/application-interactive-maps. >>>>>>> > >>>>>>> > Thanks, >>>>>>> > Fawad >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Stéphane Laurière >>>>>>> XWiki – https://xwiki.com >>>>>>> >>>>>>> >>>>>>>

Hi, Thanks for the PR Stephane! It really helps in knowing how I should do things. I will accept the PR now and make changes later if required. I tested it and everything seems fine so far except for some country facets the map goes blank (bad data handling on my part maybe). Hoping such sample data can help developing further and think in greater

details about real case scenarios.

It helps a lot, thanks. When displaying such a map, that'd be great if the available facets would

get displayed directly, without the need to enter a query in the input field (you probably have this in mind already as well).

This has been done and will be included in today's commit. I was actually writing my custom solr configurations for the map. Now that I know a use case, I can include better options. Best, Fawad On Fri, Jun 7, 2019 at 9:59 PM Stéphane Laurière <[email protected]> wrote:

Fawad, Caty, all,

I have a short comment about the tests:

...

Hi Caty, Thanks for the review.

Maps/MapTesting/Maps/TestMap - I find it strange that the Maps space is duplicated

This space exists only for testing. It won't be there for the real application. I named them so that its easier to know which type of object pages are located in them (for myself).

MapTesting, Maps, Points - spaces don't have homepages. The users will navigate to them, since they are present in breadcrumb. So what is the plan? Simpler paths? or create Homepages for these types of entry?

Since we are in the beta stage now, the whole MapTesting space exists for testing for developers. It would not be there once we have a stable version ready for release.

Actually this raises a question, all the more as we also discussed the importance of having automated functional tests earlier today on #xwiki with Vincent. For automated testing, we will need sample data, and I'm wondering where we should store this sample data (and possible scripts or code for obtaining it). How do other projects deal with test data in such a context? Is the test data stored in the same repository or in a distinct one? I was looking for some Solr application test data but could not find it yet. Note that we may consider the testing area as a set of demos instead in some way, couldn't we? It would make sense to keep it (just like if it's real test data), and to provide a navigation across these pages as you suggest it, Caty.

Cheers

Stéphane

...

Lots of pages that are not hidden. All technical pages needs to be

hidden.

...

Again, these pages are not technical and exist only for testing purposes.

A bit confusing that there are 2 search boxes for the maps, see

https://up1.xwikisas.com/#XngcOAZexsKE4DryH2i6zA

...

Yes, thanks for pointing out. We need to move the search function

directly inside the map. I will look into it once I am done with the facets.

...

For the search input, its in extremely beta stage. I am still trying to figure out the macros I have borrowed from SolrSearchMacros. So it will take time for me to make a more stable version of the facets. I hope I can do that in due time. :)

Regarding the facets, we need some more user friendly translations and customizations for this kind of UI, see https://up1.xwikisas.com/#TYj_9oLn84Mfp87VnwNgkw

As discussed earlier with Stephane, we are still having issues using the normal $facetDisplayer so we are using a workaround for testing purposes that's why it looks like this. More precisely, we are using the #displaySearchFacetValues($facetValues) macro for now.

Best, Fawad

Hi everyone, Hope all are well. Ecaterina, Stephane, For the search, do you think that we have to keep both the filter search and the search inside the map? I feel like its an important use case for the users to be able to search a location/place but that is not possible with the query search. One approach is to have a single form with select options if the the user wants to query the data or make a location search. WDYT? Here's a categorical single search form I made about a year ago: https://jsfiddle.net/9inpachi/e428fLgr/ I took a look at the application-releasenotes and what I understand is that there are sample demo pages instead of functional tests. I personally think our Interactive Maps Application aligns well with that approach and we can have the same type of tests/demos. WDYT? I would start preparing for a release for now and implement the tests once we have coordinated on how we do it. Best, Fawad On Fri, Jun 7, 2019 at 10:29 PM Vincent Massol <[email protected]> wrote:

Hi,

...

On 7 Jun 2019, at 18:59, Stéphane Laurière <[email protected]> wrote:

Fawad, Caty, all,

I have a short comment about the tests:

...

Hi Caty, Thanks for the review. Maps/MapTesting/Maps/TestMap - I find it strange that the Maps space is duplicated This space exists only for testing. It won't be there for the real application. I named them so that its easier to know which type of object pages are located in them (for myself). MapTesting, Maps, Points - spaces don't have homepages. The users will navigate to them, since they are present in breadcrumb. So what is the plan? Simpler paths? or create Homepages for these types of entry? Since we are in the beta stage now, the whole MapTesting space exists for testing for developers. It would not be there once we have a stable version ready for release.

Actually this raises a question, all the more as we also discussed the importance of having automated functional tests earlier today on #xwiki with Vincent. For automated testing, we will need sample data, and I'm wondering where we should store this sample data (and possible scripts or code for obtaining it). How do other projects deal with test data in such a context? Is the test data stored in the same repository or in a distinct one? I was looking for some Solr application test data but could not find it yet. Note that we may consider the testing area as a set of demos instead in some way, couldn't we? It would make sense to keep it (just like if it's real test data), and to provide a navigation across these pages as you suggest it, Caty.

For the Release Notes app, I also have some data for the tests. See the demo module in https://github.com/xwiki-contrib/application-releasenotes

Thanks -Vincent

...

Cheers

Stéphane

...

Lots of pages that are not hidden. All technical pages needs to be

hidden.

...

...

Again, these pages are not technical and exist only for testing purposes. A bit confusing that there are 2 search boxes for the maps, see https://up1.xwikisas.com/#XngcOAZexsKE4DryH2i6zA Yes, thanks for pointing out. We need to move the search function directly inside the map. I will look into it once I am done with the facets.

...

For the search input, its in extremely beta stage. I am still trying to figure out the macros I have borrowed from SolrSearchMacros. So it will take time for me to make a more stable version of the facets. I hope I can do that in due time. :) Regarding the facets, we need some more user friendly translations and customizations for this kind of UI, see https://up1.xwikisas.com/#TYj_9oLn84Mfp87VnwNgkw As discussed earlier with Stephane, we are still having issues using the normal $facetDisplayer so we are using a workaround for testing purposes that's why it looks like this. More precisely, we are using the #displaySearchFacetValues($facetValues) macro for now. Best, Fawad

Hi,

On 12 Jun 2019, at 20:46, Vincent Massol <[email protected]> wrote:

Hi Fawad,

...

On 12 Jun 2019, at 18:37, Fawad Ali <[email protected]> wrote:

[snip]

...

I took a look at the application-releasenotes and what I understand is that there are sample demo pages instead of functional tests.

This is not 100% correct. There are both, and the demo pages are used in the functional tests.

* Demo pages: https://github.com/xwiki-contrib/application-releasenotes/tree/master/applic... * Func tests: https://github.com/xwiki-contrib/application-releasenotes/tree/master/applic... * Demo dep in the func test module: https://github.com/xwiki-contrib/application-releasenotes/blob/master/applic...

Just realized that the release notes app is a bad example since it currently doesn’t contain any func test! They’re missing and a TODO. You could check other app like the FAQ app for an example of a func test. Sorry about that. Thanks -Vincent

Thanks -Vincent

...

I personally think our Interactive Maps Application aligns well with that approach and we can have the same type of tests/demos. WDYT?

I would start preparing for a release for now and implement the tests once we have coordinated on how we do it.

Best, Fawad

On Fri, Jun 7, 2019 at 10:29 PM Vincent Massol <[email protected]> wrote:

...

Hi,

...

On 7 Jun 2019, at 18:59, Stéphane Laurière <[email protected]> wrote:

Fawad, Caty, all,

I have a short comment about the tests:

...

Hi Caty, Thanks for the review. Maps/MapTesting/Maps/TestMap - I find it strange that the Maps space is duplicated This space exists only for testing. It won't be there for the real application. I named them so that its easier to know which type of object pages are located in them (for myself). MapTesting, Maps, Points - spaces don't have homepages. The users will navigate to them, since they are present in breadcrumb. So what is the plan? Simpler paths? or create Homepages for these types of entry? Since we are in the beta stage now, the whole MapTesting space exists for testing for developers. It would not be there once we have a stable version ready for release.

Actually this raises a question, all the more as we also discussed the importance of having automated functional tests earlier today on #xwiki with Vincent. For automated testing, we will need sample data, and I'm wondering where we should store this sample data (and possible scripts or code for obtaining it). How do other projects deal with test data in such a context? Is the test data stored in the same repository or in a distinct one? I was looking for some Solr application test data but could not find it yet. Note that we may consider the testing area as a set of demos instead in some way, couldn't we? It would make sense to keep it (just like if it's real test data), and to provide a navigation across these pages as you suggest it, Caty.

For the Release Notes app, I also have some data for the tests. See the demo module in https://github.com/xwiki-contrib/application-releasenotes

Thanks -Vincent

...

Cheers

Stéphane

...

Lots of pages that are not hidden. All technical pages needs to be

hidden.

...

...

Again, these pages are not technical and exist only for testing purposes. A bit confusing that there are 2 search boxes for the maps, see https://up1.xwikisas.com/#XngcOAZexsKE4DryH2i6zA Yes, thanks for pointing out. We need to move the search function directly inside the map. I will look into it once I am done with the facets.

...

For the search input, its in extremely beta stage. I am still trying to figure out the macros I have borrowed from SolrSearchMacros. So it will take time for me to make a more stable version of the facets. I hope I can do that in due time. :) Regarding the facets, we need some more user friendly translations and customizations for this kind of UI, see https://up1.xwikisas.com/#TYj_9oLn84Mfp87VnwNgkw As discussed earlier with Stephane, we are still having issues using the normal $facetDisplayer so we are using a workaround for testing purposes that's why it looks like this. More precisely, we are using the #displaySearchFacetValues($facetValues) macro for now. Best, Fawad

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 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. :) Also, do you foresee the map to take full browser height and width as is seen in all the examples you gave me? 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 <[email protected]> wrote:

Hi Fawad, Hi all,

...

Hi everyone, Hope all are well.

Ecaterina, Stephane, For the search, do you think that we have to keep both the filter search and the search inside the map? I feel like its an important use case for the users to be able to search a location/place but that is not possible with the query search. One approach is to have a single form with select options if the the user wants to query the data or make a location search. WDYT? Here's a categorical single search form I made about a year ago: https://jsfiddle.net/9inpachi/e428fLgr/

Imho the ability to search for a location should be an option, because not all users will need it, I think. In case it is activated, I would suggest a user experience inspired by the one exposed by GoGoCarto, the one of Google Maps, the CCI Map and the widget you mention indeed, that is made of the following elements:

1) a search input

2) only if the location search option is activated: two radio buttons for defining the scope: either the map data or a location

3) a panel that shows up upon explicit activation by the user for displaying and applying facets (on this aspect, it differs from GoGoCarto where the category filter is always present when the search widget is visible)

4) a list of search results that show up under the search widget and that can be hidden

Examples:

- https://abc.gogocarto.fr/annuaire#/carte/recherche/abc?cat=all - http://carte.preference-commerce.fr/cci-fr - https://www.google.com/maps/search/museums/@48.8761955,2.3004558,13z/data=!3...

What do you think about this approach in terms of UX?

...

I took a look at the application-releasenotes and what I understand is that there are sample demo pages instead of functional tests. I personally think our Interactive Maps Application aligns well with that approach and we can have the same type of tests/demos. WDYT?

I would start preparing for a release for now and implement the tests once we have coordinated on how we do it.

That looks like a great plan.

Cheers

Stéphane

...

Best, Fawad

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

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 <[email protected] <mailto:[email protected]>> wrote:

Hi all, I have prepared demos and have set up the repository after analyzing application-releasenotes. Please check to see if the tests and demos are working fine so we can move on to releasing the application. https://github.com/xwiki-contrib/application-interactive-maps Best, Fawad On Tue, Jun 18, 2019 at 8:25 PM Fawad Ali <[email protected]> wrote:

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? 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 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?

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.

Best, Fawad

On Mon, Jun 17, 2019 at 11:04 PM Stéphane Laurière <[email protected]> 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 <[email protected] <mailto:[email protected]>> 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 <[email protected]> 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 <[email protected] <mailto:[email protected]>> 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 <

[email protected] <mailto:[email protected]> <mailto: [email protected] <mailto:[email protected]>>> wrote:

...

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

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/ap... ) 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) <[email protected]> wrote:

Regarding tests, there are some contrib apps with tests:

https://github.com/xwiki-contrib/application-forum/tree/master/application-f...

https://github.com/xwiki-contrib/application-tour/tree/master/application-to...

Good luck with your exams, Caty

On Wed, Jun 19, 2019 at 7:32 PM Ecaterina Moraru (Valica) < [email protected]> 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 <[email protected]> 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 < [email protected] <mailto:[email protected]>> 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 <

[email protected] <mailto:[email protected]> <mailto: [email protected] <mailto:[email protected]>>> wrote:

...

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

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) <[email protected]> wrote:

On Wed, Jun 19, 2019 at 11:30 PM Fawad Ali <[email protected]> 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/ap... ) 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-basedFram... 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) < [email protected]> wrote:

...

Regarding tests, there are some contrib apps with tests:

https://github.com/xwiki-contrib/application-forum/tree/master/application-f...

https://github.com/xwiki-contrib/application-tour/tree/master/application-to...

Good luck with your exams, Caty

On Wed, Jun 19, 2019 at 7:32 PM Ecaterina Moraru (Valica) < [email protected]> 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 <[email protected]> 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 < [email protected] <mailto:[email protected]>> 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 <

[email protected] <mailto:[email protected]> <mailto: [email protected] <mailto:[email protected]>>> wrote:

...

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

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 <[email protected]> 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/ap...

...

) 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

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&doc...] 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&doc...] 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&doc...] 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&doc...] 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

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 <[email protected] <mailto:[email protected]>> 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&doc...] 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&doc...] 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&doc...] 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&doc...] 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

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 <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> 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&doc...] 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&doc...] 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&doc...] 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&doc...] 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

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

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 <[email protected]> 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 <[email protected]> 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

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/InteractiveMapsApplica... 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 <[email protected]> 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

Well done Fawad, congrats! A very small detail: we’re strying to have the same styles for images on xwiki.org and we have some guidelines linked from https://contrib.xwiki.org/xwiki/bin/view/Main/WebHome#HDocumenting For example for images here are the best practices: https://dev.xwiki.org/xwiki/bin/view/Community/DocGuide#HScreenshots2FImages So it would be awesome if you could use the {{image}} macro. Thanks -Vincent

On 16 Jul 2019, at 19:27, Fawad Ali <[email protected]> wrote:

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/InteractiveMapsApplica... 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 <[email protected]> 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

Hi Fawad, Hi all,

Hi all, Hope you are doing well.

Stephane proposed that there should be a change in the Point data structure. I agree that latitude and longitude should be two distinct fields but am not sure how we are going to accommodate geographical addresses. Should we create a separate class for an address? But if we are going to supply latitude and longitude to the map, we will need to process the addresses in some way and store their lat and lng somewhere as a point object. I am going to put this on hold until we are in the clear.

I just commented on this at https://jira.xwiki.org/browse/INTMAP-27

I have also added support for using custom class properties as addresses to feed to the map as points. This feature is available in the advanced options of map configuration. For now, the properties should be given in the form property.ClassPath.property_name e.g. property.XWiki.XWikiUsers.address_en. This is inline with how solr perceives properties.

That sounds great to use the same syntax as the Solr one indeed.

Does anyone have any suggestions for making it easier to query a class property? I will try to remove the need for the ending "_en" or "_string" part since they can prove confusing in some contexts.

+1 for removing "_en" since the app could be used in wikis where English is not enabled. I don't have further suggestion on my end so far...

I will start moving on with the development and create a mechanism for adding paths to the map.

Great, I commented also at https://jira.xwiki.org/browse/INTMAP-27 as you probably noticed, Cheers Stéphane -- Stéphane Laurière XWiki – https://xwiki.com

Hi Fawad, I would go for approach C as well, that is storing all shape data entirely in json, since most probably the shapes will either by imported directly from preexisting data in json or any equivalent, or drawn by hand on a map. I see no real use case yet for an intermediary input where part of the data would be entered via a form, then by hand. Query-wise, I don't think we will need to retrieve a huge quantity of shapes with any given property value that would need to break down some specific values into dedicated properties. In case we do some day, we could either build a dedicated index I would say, or fill in dedicated properties automatically from the json input via a listener. Cheers, Stéphane

Hi Stéphane, Ecaterina and everyone, Hope you all had a wonderful weekend.

So I am working on shapes and wanted to know how I should deal with the large number of options for each shape type. As expected, the options are different for each shape type.

I have multiple approaches in mind for this: *Approach A:* Using the normal properties of XClass, create all the options for a shape type as properties for that class. This will in turn increase the class size as a lot of options will exist for each shape type. *Approach B:* Use a static list or array to define the value of each shape type option. I have tried and it seems we cannot make use of key value pairs in static list or any other data type in XWiki so I am not completely sure of the implementation using static lists. *Approach C:* Create a single TextArea property for options in each shape type class. The user can pass a JSON of options in that TextArea. Imho I prefer this approach since JSON is a standard format and it will give the user freedom of which options to use.

WDYT?

Best, Fawad Ali

Hi Fawad, Thanks for the update. I had a look at the ShapeClass and I have a remark about their structure. I see you introduced the properties "points", "type". I'm wondering whether we could simply consider that the shapes are entirely represented in GeoJSON, including the style options, just like http://geojson.io/ behaves, eg in the example below. What would be the use case for storing these properties separately? I thought your previous question were about that, sorry for the misunderstanding. Regarding the editors: good to see there's the point editor (I had not tried it yet), I have some remarks about it: - What about setting it up by default for the PointClass objects, so that these points can be edited using the editor, by creating a PointSheet that uses it? - We could introduce a TemplateProvider for points, so that creating points can be achieved using the standard XWiki create page, what do you think? - What's the rationale for storing the editors in a dedicated space? I would either put all them in the Code space directly, or in a subspace if you really want to group them (I tend to avoid having too many nested spaces but that's a personal taste only). I may have other remarks that I will bring up directly on Jira if that's ok with you. It's good to read that you already have in mind indoor maps as it's a promising feature imho, on the other hand I'd say there could be also much value in improving the current features, I need to get my head around that and to review the current issues. I will do so by tomorrow, then we could set up a call at the end of the day, if possible for you, or on Monday. What about 3pm UTC tomorrow? Or Monday 3pm UTC? Cheers Stéphane { "type": "Feature", "properties": { "stroke": "#c5ce00", "stroke-width": 2, "stroke-opacity": 1, "fill": "#c13d3d", "fill-opacity": 0.5 }, "geometry": { "type": "Polygon", "coordinates": [ [ [ 148.7109375, 54.36775852406841 ], [ 146.95312499999997, 54.16243396806779 ], [ 170.5078125, 6.664607562172573 ], [ 216.2109375, 40.17887331434696 ], [ 198.98437499999997, 76.01609366420995 ], [ 148.7109375, 54.36775852406841 ] ] ] } }

Hi all,

The setup for shapes has been done. What I have in mind now is to have a Shape Editor similar to the Point Editor with interactive tools to create shapes. Stephane, if you have anything else in mind for interactively creating shapes then please let me know so that we are on the same page. I will work on it as fast as I can so we can move on to the implementation of Indoor Maps.

Best, Fawad Ali -- Stéphane Laurière XWiki – https://xwiki.com

Stéphane, I agree that GeoJSON would be a much portable and standard option. I went with the structure I implemented because I was directly working with leaflet docs. I have one concern though and that is the flexibility of GeoJSON. By flexibility I mean that it will be harder for XWiki users to get used to the GeoJSON as opposed to the "points" and "options" properties of ShapeClass. Nonetheless, I am going with the GeoJSON now. Best, Fawad On Thu, Aug 1, 2019 at 11:37 PM Stéphane Laurière <[email protected]> wrote:

Fawad, Caty,

I had mostly technical aspects in mind when proposing a call, I overlooked that UX and design also need to be discussed so that we make sure to align our views for the upcoming weeks. Let's see in a private channel how we can align our agenda to make this happen, if you feel like it. Apologies for having acted a bit in a rush.

Cheers

Stéphane

...

Hi all,

The setup for shapes has been done. What I have in mind now is to have a Shape Editor similar to the Point Editor with interactive tools to create shapes. Stephane, if you have anything else in mind for interactively creating shapes then please let me know so that we are on the same page. I will work on it as fast as I can so we can move on to the implementation of Indoor Maps.

Best, Fawad Ali

On Tue, Jul 30, 2019 at 11:46 AM Stéphane Laurière <[email protected] <mailto:[email protected]>> wrote:

Hi Fawad,

I would go for approach C as well, that is storing all shape data entirely in json, since most probably the shapes will either by imported directly from preexisting data in json or any equivalent, or drawn by hand on a map. I see no real use case yet for an intermediary input where part of the data would be entered via a form, then by hand. Query-wise, I don't think we will need to retrieve a huge quantity of shapes with any given property value that would need to break down some specific values into dedicated properties. In case we do some day, we could either build a dedicated index I would say, or fill in dedicated properties automatically from the json input via a listener.

Cheers,

Stéphane

> Hi Stéphane, Ecaterina and everyone, > Hope you all had a wonderful weekend. > > So I am working on shapes and wanted to know how I should deal with the large number of options for each shape type. As expected, the options are different for each shape type. > > I have multiple approaches in mind for this: > *Approach A:* Using the normal properties of XClass, create all the options for a shape type as properties for that class. This will in turn increase the class size as a lot of options will exist for each shape type. > *Approach B:* Use a static list or array to define the value of each shape type option. I have tried and it seems we cannot make use of key value pairs in static list or any other data type in XWiki so I am not completely sure of the implementation using static lists. > *Approach C:* Create a single TextArea property for options in each shape type class. The user can pass a JSON of options in that TextArea. Imho I prefer this approach since JSON is a standard format and it will give the user freedom of which options to use. > > WDYT? > > Best, > Fawad Ali

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