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 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 m.fawaadali98@gmail.com 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, 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) valicac@gmail.com 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 m.fawaadali98@gmail.com 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,
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 enygma2002@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com
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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com
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, 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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com
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
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 enygma2002@gmail.com 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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com
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,
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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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) < valicac@gmail.com> 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 <m.fawaadali98@gmail.com
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) valicac@gmail.com 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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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) < valicac@gmail.com> 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 <m.fawaadali98@gmail.com
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 >
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 vincent@massol.net 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) valicac@gmail.com
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 m.fawaadali98@gmail.com
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 enygma2002@gmail.com 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 m.fawaadali98@gmail.com 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 enygma2002@gmail.com 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) < valicac@gmail.com> 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 <m.fawaadali98@gmail.com
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) <valicac@gmail.com 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 vincent@massol.net 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) <valicac@gmail.com
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 m.fawaadali98@gmail.com
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 enygma2002@gmail.com 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 m.fawaadali98@gmail.com 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%3E
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 <enygma2002@gmail.com
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) < > valicac@gmail.com> > 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 <
m.fawaadali98@gmail.com
> 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 Fawad,
On 20 May 2019, at 18:12, Fawad Ali m.fawaadali98@gmail.com 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) <valicac@gmail.com 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 vincent@massol.net 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) <valicac@gmail.com
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 m.fawaadali98@gmail.com
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 enygma2002@gmail.com 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 m.fawaadali98@gmail.com 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%3E
> 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 <enygma2002@gmail.com
> 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) < >> valicac@gmail.com> >> 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 <
m.fawaadali98@gmail.com
>> 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 vincent@massol.net wrote:
Hi Fawad,
On 20 May 2019, at 18:12, Fawad Ali m.fawaadali98@gmail.com 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) <
valicac@gmail.com
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 vincent@massol.net
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) <
valicac@gmail.com
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 m.fawaadali98@gmail.com
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 enygma2002@gmail.com 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 <m.fawaadali98@gmail.com
> 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%3E
>> 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 <
enygma2002@gmail.com
>> 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) < >>> valicac@gmail.com> >>> 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 <
m.fawaadali98@gmail.com
> >>> 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 >>>>> >>>> >>> >> >
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 m.fawaadali98@gmail.com 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 vincent@massol.net wrote:
Hi Fawad,
On 20 May 2019, at 18:12, Fawad Ali m.fawaadali98@gmail.com 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) <
valicac@gmail.com
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 vincent@massol.net
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) <
valicac@gmail.com
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 m.fawaadali98@gmail.com
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 <
enygma2002@gmail.com>
> 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 <
m.fawaadali98@gmail.com
>> 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%3E
>>> 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 <
enygma2002@gmail.com
>>> 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) < >>>> valicac@gmail.com> >>>> 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 <
m.fawaadali98@gmail.com
>> >>>> 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com 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 vincent@massol.net
wrote:
Hi Fawad,
On 20 May 2019, at 18:12, Fawad Ali m.fawaadali98@gmail.com 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) <
valicac@gmail.com
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 vincent@massol.net
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) <
valicac@gmail.com
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 <
m.fawaadali98@gmail.com>
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 <
enygma2002@gmail.com>
>> 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 <
m.fawaadali98@gmail.com
>>> 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 <
enygma2002@gmail.com
>>>> 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) < >>>>> valicac@gmail.com> >>>>> 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 <
m.fawaadali98@gmail.com
>>> >>>>> 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 Fri, May 24, 2019 at 9:19 PM Fawad Ali m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com
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 vincent@massol.net
wrote:
Hi Fawad,
On 20 May 2019, at 18:12, Fawad Ali m.fawaadali98@gmail.com
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) <
valicac@gmail.com
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 <
vincent@massol.net>
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) <
valicac@gmail.com
> > 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 <
m.fawaadali98@gmail.com>
> 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 <
enygma2002@gmail.com>
>>> 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 <
m.fawaadali98@gmail.com
>>>> 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 <
enygma2002@gmail.com
> >>>>> 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) < >>>>>> valicac@gmail.com> >>>>>> 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 < m.fawaadali98@gmail.com >>>> >>>>>> 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) valicac@gmail.com wrote:
On Fri, May 24, 2019 at 9:19 PM Fawad Ali m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com
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 vincent@massol.net
wrote:
Hi Fawad,
On 20 May 2019, at 18:12, Fawad Ali m.fawaadali98@gmail.com
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) <
valicac@gmail.com
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 <
vincent@massol.net>
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) <
valicac@gmail.com
>> >> 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 <
m.fawaadali98@gmail.com>
>> 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 <
enygma2002@gmail.com>
>>>> 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 <
m.fawaadali98@gmail.com
>>>>> 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 <
enygma2002@gmail.com
>> >>>>>> 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)
<
>>>>>>> valicac@gmail.com> >>>>>>> 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 < > m.fawaadali98@gmail.com >>>>> >>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >> >
Some notes:
* The maps are not working anymore with the recent commits. There is an error in console: {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 really dislike the Maps space :) inside the Map, maybe because my expectation is to have something like Maps > Map, but still in terms of structure we can do some improvements. But this is minor.
* 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)? ** 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?
* Maps will also be pages, containing configuration (custom backgrounds), etc.
Thanks, Caty
On Tue, May 28, 2019 at 11:22 AM Fawad Ali m.fawaadali98@gmail.com wrote:
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) < valicac@gmail.com> wrote:
On Fri, May 24, 2019 at 9:19 PM Fawad Ali m.fawaadali98@gmail.com
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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com
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 <vincent@massol.net
wrote:
Hi Fawad,
> On 20 May 2019, at 18:12, Fawad Ali m.fawaadali98@gmail.com
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) < valicac@gmail.com > 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 <
vincent@massol.net>
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) < valicac@gmail.com >>> >>> 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 <
m.fawaadali98@gmail.com>
>>> 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 <
enygma2002@gmail.com>
>>>>> 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 <
m.fawaadali98@gmail.com
> >>>>>> 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 < enygma2002@gmail.com >>> >>>>>>> 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)
<
>>>>>>>> valicac@gmail.com> >>>>>>>> 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 < >> m.fawaadali98@gmail.com >>>>>> >>>>>>>> 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
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 slauriere@xwiki.com 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
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 <slauriere@xwiki.com mailto:slauriere@xwiki.com> 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,
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 slauriere@xwiki.com 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Caty, Fawad, all, [...] > * I've read again the GSOC project description. The main purposeof the
> application is to allow multiple people to create POIs and othershapes on
> the Maps. There is a note that the POIs will have additionalinformation
> about the location. > Some questions: > ** can a POI be displayed in multiple Maps? For example: if wesomeone
> creates a 'Centre Pompidou' POI in a page, where adds informationabout the
> place, images, etc. Should we be able to display this POI inmultiple maps
> (one that contains museums, while others contain modernarchitecture)?
I would say it's important that a point of interest or any otherentity 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 inindividual
> pages. We need to think about performance too. Pages will lots ofobjects
> can have performance issues, so storing as pages (that willcontain 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 startwith. 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 (custombackgrounds),
> etc. Indeed, a map page will consist of a map configuration imho. We needto 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 m.fawaadali98@gmail.com 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 slauriere@xwiki.com 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Caty, Fawad, all, [...] > * I've read again the GSOC project description. The main purposeof the
> application is to allow multiple people to create POIs and othershapes on
> the Maps. There is a note that the POIs will have additionalinformation
> about the location. > Some questions: > ** can a POI be displayed in multiple Maps? For example: if wesomeone
> creates a 'Centre Pompidou' POI in a page, where addsinformation about the
> place, images, etc. Should we be able to display this POI inmultiple maps
> (one that contains museums, while others contain modernarchitecture)?
I would say it's important that a point of interest or any otherentity 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 inindividual
> pages. We need to think about performance too. Pages will lotsof objects
> can have performance issues, so storing as pages (that willcontain 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 startwith. 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 (custombackgrounds),
> etc. Indeed, a map page will consist of a map configuration imho. Weneed 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, Caty, all,
Stéphane,
I will start off by learning Solr Search Query API and see how I can use it in this application.
Great
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.
Imho we will need both. On the one hand, what you prototyped with map editors will be useful for adding or editing data items – I foresee more one single editor providing all the editing features than several distinct ones though, what do you think? On the other hand, we will also use queries to generate maps indeed.
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?
I think we should start with having one page per object and that the query defined at the Map object level will gather all the data to be displayed on the map. Then, subqueries built on top of the primary one (adding full-text, facets or spatial constraints) will let the user filter the existing elements. Having one page per object will make it easy to associate content and images to each geographical object: they will be the content and the attachments of the page itself. What do you think? Having several objects attached to one page could be useful as well in a second step I would say, for more advanced use cases covering pages that relate to several distinct locations (e.g. a place that consists of several points and splitted areas).
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.
Here's a reference to an application that provides a user experience that is close to what I have in mind, a sample map that I created on the GoGoCarto site: https://abc.gogocarto.fr/ (French language again though). From there, hit the link "La carte" at the top right, then "Ajouter un élément" (you can also get you an account for accessing the administration user interface). You will see a form with a basic map editor for adding a point. It's close to my view in the sense that it provides two distinct interfaces for 1) editing data, with a (basic) map editor, 2) rendering the interactive map itself. From that perspective, we're more aiming at a map renderer than at an advanced map editor, compared to what the XWiki diagram editor application is, for instance. But we will still need an editor for editing individual points, shapes, paths, or even a few of them combined, when editing a metro line for instance, but not a whole map at once.
Does this make the goal clearer and still meaningful to you? I would say imho that we're aiming at a map application, since what users will produce or use is an interactive map, but the application will hinge on an advanced map service (or several ones) indeed. I feel like we're just aligning our views (I hope) on a project with a certain level of complexity, I would not call that confusion!
Side note: later on in the development process and depending if it makes sense for the XWiki product itself or not, we (the XWiki developer community at large) could consider making points, shapes and paths primary XWiki property types that could be used in any XWiki Class, so that the production of forms comprising geographical data can be made even more simple, but we're not there yet. This approach could be compared at least partly to what GeoDjango brings to Django (I think): https://docs.djangoproject.com/en/2.2/ref/contrib/gis/
Maybe we can have a recorded video/audio conference as that will save us a lot of time discussing these things. WDYT?
Sure, good idea, I'll send you some slot proposals to you and Caty.
Cheers
Stéphane
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
Hi Fawad, Caty, all,
Fawad, I think that what you did is a great start.
I would propose at this stage that we refine the use cases of what we aim at, and that we describe further the architecture and implementation plans accordingly.
I brought the following changes to the design page toward these goals:
- Description of three use cases - Renaming of the "Implementation" section into "Architecture" (it contains also some implementation aspects indeed, but I feel like we're more at the architecture design there, let me know what you think) - Addition of one subsection about the data model, another one about the needed services (APIs) - Creation of a section related to data samples, which are likely to be needed while we progress further - Renaming of the "Expected results" section into "Mockups"
https://design.xwiki.org/xwiki/bin/view/Proposal/MapApplication
Please let me know what you think about the use cases and the other changes that I brought the design page proposal? I'll be able to provide feedback and suggestions about the next steps both at the functional and technical levels as soon as I get your view on that.
Cheers
Stéphane
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,
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 slauriere@xwiki.com 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 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 m.fawaadali98@gmail.com 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 slauriere@xwiki.com 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 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+Application#HCreatetheTemplateProvider
== 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 <m.fawaadali98@gmail.com mailto:m.fawaadali98@gmail.com> 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 <slauriere@xwiki.com <mailto:slauriere@xwiki.com>> 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 slauriere@xwiki.com 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 <m.fawaadali98@gmail.com
mailto:m.fawaadali98@gmail.com> 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 provideyou with updates soon.
Best, Fawad On Wed, May 29, 2019 at 4:34 PM Stéphane Laurière <slauriere@xwiki.com mailto:slauriere@xwiki.com> 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 onthe map, and the Solr facets to apply additional filters
- The data returned by the Solr API will be converted toGeoJSON. 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 fieldstoring 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) aset 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 sothat the data can be consumed and displayed by Leaflet
Fawad, please don't hesitate to mention any complementary aspectthat I may have forgotten or questions you may have.
Cheers Stéphane-- Stéphane Laurière XWiki – https://xwiki.com
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
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 <slauriere@xwiki.com 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
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 m.fawaadali98@gmail.com 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 <slauriere@xwiki.com 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 m.fawaadali98@gmail.com 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 m.fawaadali98@gmail.com 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 <slauriere@xwiki.com 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, 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) <valicac@gmail.com 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 m.fawaadali98@gmail.com 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 m.fawaadali98@gmail.com 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 <slauriere@xwiki.com 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 m.fawaadali98@gmail.com 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) <valicac@gmail.com 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 m.fawaadali98@gmail.com 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 m.fawaadali98@gmail.com 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 <slauriere@xwiki.com 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
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) <valicac@gmail.com 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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 m.fawaadali98@gmail.com 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 <slauriere@xwiki.com 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 <m.fawaadali98@gmail.com 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) <valicac@gmail.com 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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 m.fawaadali98@gmail.com 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 <slauriere@xwiki.com 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 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%E2%8... 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 m.fawaadali98@gmail.com 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 <m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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 m.fawaadali98@gmail.com 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 <slauriere@xwiki.com > 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) valicac@gmail.com 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%E2%8... 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 m.fawaadali98@gmail.com 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 <m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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 m.fawaadali98@gmail.com > 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 < >> slauriere@xwiki.com 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 >>> >>> >>>
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 m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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%E2%8... 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 m.fawaadali98@gmail.com 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 <m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com > 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 m.fawaadali98@gmail.com >> 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 < >>> slauriere@xwiki.com 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) valicac@gmail.com 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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%E2%8... 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 m.fawaadali98@gmail.com 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 <m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com 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) < > valicac@gmail.com 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 m.fawaadali98@gmail.com >> 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 m.fawaadali98@gmail.com >>> 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 < >>>> slauriere@xwiki.com 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,
On Fri, Jun 7, 2019 at 2:01 PM Fawad Ali m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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%E2%8... 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 m.fawaadali98@gmail.com 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 <m.fawaadali98@gmail.com 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) < valicac@gmail.com 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 m.fawaadali98@gmail.com > 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) < >> valicac@gmail.com 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 m.fawaadali98@gmail.com >>> 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 m.fawaadali98@gmail.com >>>> 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 < >>>>> slauriere@xwiki.com 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
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) valicac@gmail.com wrote:
Hi,
On Fri, Jun 7, 2019 at 2:01 PM Fawad Ali m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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 m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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%E2%8... 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 m.fawaadali98@gmail.com 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 <m.fawaadali98@gmail.com 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) < > valicac@gmail.com 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 m.fawaadali98@gmail.com >> 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) < >>> valicac@gmail.com 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 m.fawaadali98@gmail.com >>>> 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 < >>>>> m.fawaadali98@gmail.com> 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 < >>>>>> slauriere@xwiki.com 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 >>>>>>> >>>>>>> >>>>>>>
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 duplicatedThis 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/#XngcOAZexsKE4DryH2i6zAYes, 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_9oLn84Mfp87VnwNgkwAs 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,
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 slauriere@xwiki.com 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 spaceis 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 userswill 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 behidden.
Again, these pages are not technical and exist only for testing purposes.
A bit confusing that there are 2 search boxes for the maps, seehttps://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 translationsand 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 7 Jun 2019, at 18:59, Stéphane Laurière slauriere@xwiki.com 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 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 vincent@massol.net wrote:
Hi,
On 7 Jun 2019, at 18:59, Stéphane Laurière slauriere@xwiki.com 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 Fawad,
On 12 Jun 2019, at 18:37, Fawad Ali m.fawaadali98@gmail.com 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...
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 vincent@massol.net wrote:
Hi,
On 7 Jun 2019, at 18:59, Stéphane Laurière slauriere@xwiki.com 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 vincent@massol.net wrote:
Hi Fawad,
On 12 Jun 2019, at 18:37, Fawad Ali m.fawaadali98@gmail.com 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 vincent@massol.net wrote:
Hi,
On 7 Jun 2019, at 18:59, Stéphane Laurière slauriere@xwiki.com 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 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
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 slauriere@xwiki.com 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:
a search input
only if the location search option is activated: two radio buttons for
defining the scope: either the map data or a location
- 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)
- 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 all,
I am still a little confused regarding tests. What I get from analyzing the application-release-notes is that I have to make demo pages containing maps first, then just include test (containing demo pages) and ui folders and change the pom files to include the tests, is that correct?
Thanks, Fawad
On Sat, Jun 15, 2019 at 5:42 PM Fawad Ali m.fawaadali98@gmail.com wrote:
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 slauriere@xwiki.com 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:
a search input
only if the location search option is activated: two radio buttons for
defining the scope: either the map data or a location
- 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)
- 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com> 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 slauriere@xwiki.com 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> 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 m.fawaadali98@gmail.com 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 slauriere@xwiki.com 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> 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 requestJust 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com> 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 <slauriere@xwiki.com <mailto:slauriere@xwiki.com> <mailto:slauriere@xwiki.com <mailto:slauriere@xwiki.com>>> 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 slauriere@xwiki.com wrote:
Hi Fawad, hi all,
Hi all,
I just gave a try to the latest code, well done with the Solrqueries 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 getactivated, 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 aswell, 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Fawad, Caty, all, > Hi all, > Hoping that everything is going well. > > Stephane, I was able to do implement most of your suggestionsexcept the search results list.
I just gave a try to the latest code, well done with the Solrqueries and the search integration in the user interface, that's cool!
> I am not too sure where I should place it. As per the latestbuild, 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 getactivated, 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 aswell, and can be completely hidden on request
It's rather close to what Google Maps proposes as well, except thatthe 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 andwidth 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 itfull-screen indeed, similarly to what happens with the XWiki text editor.
Cheers Stéphane > Regarding the release, I will try preparing everything by tonightso 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com <mailto: slauriere@xwiki.com mailto:slauriere@xwiki.com>> wrote:
-- Stéphane Laurière XWiki – https://xwiki.com
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) valicac@gmail.com 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 slauriere@xwiki.com wrote:
Hi Fawad, hi all,
Hi all,
I just gave a try to the latest code, well done with the Solrqueries 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 getactivated, 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 aswell, 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Fawad, Caty, all, > Hi all, > Hoping that everything is going well. > > Stephane, I was able to do implement most of your suggestionsexcept the search results list.
I just gave a try to the latest code, well done with the Solrqueries and the search integration in the user interface, that's cool!
> I am not too sure where I should place it. As per the latestbuild, 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 getactivated, 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 aswell, and can be completely hidden on request
It's rather close to what Google Maps proposes as well, except thatthe 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 andwidth 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 itfull-screen indeed, similarly to what happens with the XWiki text editor.
Cheers Stéphane > Regarding the release, I will try preparing everything bytonight 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com <mailto: slauriere@xwiki.com mailto:slauriere@xwiki.com>> 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) valicac@gmail.com 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) < valicac@gmail.com> 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 slauriere@xwiki.com wrote:
Hi Fawad, hi all,
Hi all,
I just gave a try to the latest code, well done with the Solrqueries 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 getactivated, 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 aswell, 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 <
slauriere@xwiki.com mailto:slauriere@xwiki.com> wrote:
Hi Fawad, Caty, all, > Hi all, > Hoping that everything is going well. > > Stephane, I was able to do implement most of your suggestionsexcept the search results list.
I just gave a try to the latest code, well done with the Solrqueries and the search integration in the user interface, that's cool!
> I am not too sure where I should place it. As per the latestbuild, 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 getactivated, 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 aswell, and can be completely hidden on request
It's rather close to what Google Maps proposes as well, exceptthat 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 andwidth as is seen in all the examples you gave me?
That would be a nice feature to have a button on the map to turnit full-screen indeed, similarly to what happens with the XWiki text editor.
Cheers Stéphane > Regarding the release, I will try preparing everything bytonight 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com <mailto: slauriere@xwiki.com mailto:slauriere@xwiki.com>> wrote:
-- Stéphane Laurière XWiki – https://xwiki.com
On Wed, Jun 19, 2019 at 11:30 PM Fawad Ali m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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) < valicac@gmail.com> 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 slauriere@xwiki.com wrote:
Hi Fawad, hi all,
Hi all,
I just gave a try to the latest code, well done with the Solrqueries 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 getactivated, 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 overlayas 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 <
slauriere@xwiki.com mailto:slauriere@xwiki.com> wrote:
Hi Fawad, Caty, all, > Hi all, > Hoping that everything is going well. > > Stephane, I was able to do implement most of your suggestionsexcept the search results list.
I just gave a try to the latest code, well done with the Solrqueries and the search integration in the user interface, that's cool!
> I am not too sure where I should place it. As per the latestbuild, 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 getactivated, 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 overlayas well, and can be completely hidden on request
It's rather close to what Google Maps proposes as well, exceptthat 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 andwidth as is seen in all the examples you gave me?
That would be a nice feature to have a button on the map to turnit full-screen indeed, similarly to what happens with the XWiki text editor.
Cheers Stéphane > Regarding the release, I will try preparing everything bytonight 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com <mailto: slauriere@xwiki.com mailto:slauriere@xwiki.com>> 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) valicac@gmail.com wrote:
On Wed, Jun 19, 2019 at 11:30 PM Fawad Ali m.fawaadali98@gmail.com 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) < valicac@gmail.com> 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) < valicac@gmail.com> 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 slauriere@xwiki.com wrote:
Hi Fawad, hi all,
Hi all,
I just gave a try to the latest code, well done with the Solrqueries 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 getactivated, 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 overlayas 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 <
slauriere@xwiki.com mailto:slauriere@xwiki.com> wrote:
Hi Fawad, Caty, all, > Hi all, > Hoping that everything is going well. > > Stephane, I was able to do implement most of your suggestionsexcept the search results list.
I just gave a try to the latest code, well done with the Solrqueries and the search integration in the user interface, that's cool!
> I am not too sure where I should place it. As per the latestbuild, 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 getactivated, 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 overlayas well, and can be completely hidden on request
It's rather close to what Google Maps proposes as well, exceptthat 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 andwidth as is seen in all the examples you gave me?
That would be a nice feature to have a button on the map to turnit full-screen indeed, similarly to what happens with the XWiki text editor.
Cheers Stéphane > Regarding the release, I will try preparing everything bytonight 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com <mailto: slauriere@xwiki.com mailto:slauriere@xwiki.com>> wrote:
-- Stéphane Laurière XWiki – https://xwiki.com
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 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 slauriere@xwiki.com 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 all, Hope everyone is well.
Please review the application developed so far. I have included a UI test and map states. I think we should release the application as soon as we can so that user reviews can be gathered.
Best, Fawad
On Mon, Jul 1, 2019, 8:26 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi everyone, Hope to find you well.
Their flow is actually completely in line with what I have in mind as well
(except I may prefer personaly to have the facet above the result list items, to be discussed...)
That would certainly be better in my opinion.
I would expect the search button to be closer to the area where the widget
pops in, that is on the left side in our current setup, what do you think?
It was that way in the previous commits. But the idea of this approach is to have the left side completely blank with no controls. What it helps in is to provide a dedicated space for both the popup and search widget. If we place the search control on the top left, our search control is hidden when either popup or the search widget is enabled. And if we place the search widget right beside the search control (to the right of it), it will take unnecessary space. One option is to have the close icon to the right of the search widget popup but it still doesn't fix the problem of search control hiding when the marker popup is opened.
Indeed, that's an issue. Regarding facets, page Main.SolrSearch behaves
similarly as far as I understand, and manages to keep the facets in the same state visually as how they were before launching the asychronous call, doesn't it? So I was thinking we could use the same approach, or is there a hidden complexity? As for the search input: the input itself can be retrieved from the URL, so we should be able to restore it as well, don't we? Can you clarify how separating in two distinct services may help? We will need to consider the other states of the map that we want to represent in the URL so that specific map states can be shared easily, we could add the current selection to the URL's fragment, what do you think?
That's exactly what I eventually had in mind besides the JSON service. For the JSON service, we could have a common place for retrieving any kind of map data, like a REST API but that was the secondary approach. What we could do now is utilize the URL parameters. For now, I am thinking of having a multiple URL parameter that can contain different states of the map. For example, if we have both the fullscreen and search popup enabled, we could have the URL parameters "?mfullscreen=true&msearchw=true" where mfullscreen = map full screen and msearchw = map search widget. Other parameters like this can be added for different states. WDYT?
We came up with a possible workaround with Anca, which consists in using
the Velocity "evaluate" macro in order to force the usage of the current Velocity context (replace "scriptPage" by "facetDisplayer"):
#set ($script = $!scriptPage.content.replaceAll('{{/{0,2}velocity}}', '')) #evaluate($script)
I gave a try to this solution and it worked fine on my end on the example mentioned on the forum (not tested yet with the facetDisplayers). We need to investigate further though:
That's great, I will check it out as soon as I am able.
Best, Fawad
On Fri, Jun 28, 2019 at 3:02 PM Stéphane Laurière slauriere@xwiki.com 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&...] 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&...] 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&...] 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&...] 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
I have fixed the errors you mentioned. It appears one of the variables had a bad name which was causing the error.
On the UI side, possibly as a consequence, I can't see a list of results
anymore, and the search widget state is not restored.
The list of results is just fine on my end, I am not sure what could be wrong. About the map state, it does not work well with facets. Since facets have a separate code we cannot apply custom code when a facet is selected thus limiting our ability to pass the map state through js. I tried looking around for related js events but could not find one through which we can pass the map state after a facet is clicked. Do you have anything in mind for this?
I think the name "Maps.Code.Leaflet" might be misleading for potential
developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think?
I think its fine as is. Since it is placed inside the Code space, the developers will immediately be able to know that all the Leaflet related code resides inside it. But to be on the safe side, we can rename it to LeafletMap as in the macro-map.
Ludovic just suggested an improvement (for the next versions): let the user
configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used.
Thanks Ludovic for your suggestion. I would look into the calendar application to have a better understanding of this and let you know my thoughts.
Best, Fawad
On Wed, Jul 10, 2019 at 2:55 PM Stéphane Laurière slauriere@xwiki.com 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&...] 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&...] 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&...] 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&...] 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com> wrote:
Hi Fawad, Good to hear from you again, I hope things are fine on your end as well. Thanks for the update. Sorry for the delay, we were traveling yesterday. Releasing the application soon sounds good. I'm facing a few issues though, they may be related to an installation issue on my side, not sure. I grabbed the latest code and imported as a XAR over the existing pages in my 11.x wiki without error, and I notice the following (I'll consider posting some Jira issues if needed): - catalina.out errors (not sure if they were present with previous version): 2019-07-10 11:34:30,349 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN c.x.x.w.s.JsExtension - Error at line 203, column 85: missing variable name. Caused by: [ var index = 0, lat = 0, lng = 0, coordinates = [], shift = 0, result = 0, byte = null, latitude_change, longitude_change, factor = Math.pow(10, Number.isInteger(precision) ? precision : 5);] 2019-07-10 11:34:30,350 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN c.x.x.w.s.JsExtension - Error at line 206, column 13: identifier is a reserved word. Caused [...] 2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] ERROR c.x.x.w.s.JsExtension - Runtime error minimizing JSX object: Compilation produced 8 syntax errors. 2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN c.x.x.w.s.JsExtension - Failed to compress JS extension: null - On the UI side, possibly as a consequence, I can't see a list of results anymore, and the search widget state is not restored. - I notice there is no default radio button checked in the search form: I think either "location" or "item" should be checked, to let the user know what's the default (I'd say "item"). - I think the name "Maps.Code.Leaflet" might be misleading for potential developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think? - Ludovic just suggested an improvement (for the next versions): let the user configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used. Cheers Stéphane Fawad Ali: > Hi all, > Hope everyone is well. > > Please review the application developed so far. I have included a UI test and map states. I think we should release the application as soon as we can so that user reviews can be gathered. > > Best, > Fawad
Hi all,
However, as a user I would expect the list to be present also when the
search input is empty, with the possibility to reduce the list by hitting the link "Show result items", what do you think?
By this do you mean that all the results should show in the "Show result items" when the search is empty? Thereby decreasing the number of result items when an actual search is made.
Speaking of the list, that'd be great imho that the popups can be displayed
while the list is active, so that the user can browse content via the list, wouldn't it?
I am not too sure where we could place them, since both the list and popups take a large amount of space. The popups are build to support page data, so they are also big. We could do it so the upper space belongs to the popup and the lower space belongs to the list. Though it will cramp the space a little imo. We could also increase the overall height of the map (which is 400px for now). WDYT?
Restoring the full screen is working in most cases, that's cool, however
if I run a search, then enter full screen, then refine the search, it seems that the full screen state is not preserved, is it?
That's one use case which leads to a loss of the previous map state and the one before that is used. Any state before the facet click is not preserved except the search widget and "Refine your search" area which is more or less forced. As I said before, the problem is that we cannot pass the state anywhere when a facet is clicked. I will look into cumulative onclick events but I think that's not going to work.
I agree LeafletMap would be closer to what it does, but contrarily to the
Macro Map, if I'm not mistaken, the page currently named Maps.Code.Leaflet does not create a JavaScript LeafletMap class, so technically it's more a LeafletUtils than a LeafletMap, isn't it?
You are right, it does not create any js class and since css is also inside the same page the name should be LeafletUtils or LeafletService. I will change it accordingly.
Also, I looked into it and the idea of custom class property for getting the location is interesting indeed. I will see how I should prioritize it and implement it then since we have other major features to look into.
I would also like to ask; what do you foresee as the basic elements of the application? We have map configuration, map query, search and filter widget, markers and popups so far. Do you have anything other than this in mind that could be thought of as the basis of the application? I think we should completely stabilize the basics by the end of this week so I can work on other features like map paths, indoor maps and custom shapes.
Best, Fawad
On Thu, Jul 11, 2019 at 1:50 PM Stéphane Laurière slauriere@xwiki.com 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 ofresults 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 forpotential 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): letthe 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Fawad, Good to hear from you again, I hope things are fine on your end aswell. 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 previousversion):
2019-07-10 11:34:30,349 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&...] 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&...] 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&...] 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&...] 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 ofresults anymore, and the search widget state is not restored.
- I notice there is no default radio button checked in the searchform: 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 forpotential 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): letthe 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 aUI 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?
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):
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 <slauriere@xwiki.com mailto:slauriere@xwiki.com> 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 <slauriere@xwiki.com <mailto:slauriere@xwiki.com> <mailto:slauriere@xwiki.com <mailto:slauriere@xwiki.com>>> wrote: > > Hi Fawad, > > Good to hear from you again, I hope things are fine on your end as well. Thanks for the update. Sorry for the delay, we were traveling yesterday. Releasing the application soon sounds good. I'm facing a few issues though, they may be related to an installation issue on my side, not sure. I grabbed the latest code and imported as a XAR over the existing pages in my 11.x wiki without error, and I notice the following (I'll consider posting some Jira issues if needed): > > - catalina.out errors (not sure if they were present with previous version): > > 2019-07-10 11:34:30,349 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN c.x.x.w.s.JsExtension - Error at line 203, column 85: missing variable name. Caused by: [ var index = 0, lat = 0, lng = 0, coordinates = [], shift = 0, result = 0, byte = null, latitude_change, longitude_change, factor = Math.pow(10, Number.isInteger(precision) ? precision : 5);] > 2019-07-10 11:34:30,350 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN c.x.x.w.s.JsExtension - Error at line 206, column 13: identifier is a reserved word. Caused [...] > 2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] ERROR c.x.x.w.s.JsExtension - Runtime error minimizing JSX object: Compilation produced 8 syntax errors. > 2019-07-10 11:35:02,841 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&docVersion=5.1] WARN c.x.x.w.s.JsExtension - Failed to compress JS extension: null > > - On the UI side, possibly as a consequence, I can't see a list of results anymore, and the search widget state is not restored. > > - I notice there is no default radio button checked in the search form: I think either "location" or "item" should be checked, to let the user know what's the default (I'd say "item"). > > - I think the name "Maps.Code.Leaflet" might be misleading for potential developers: this could mean this page is providing Leaflet, while it does not. I would suggest to choose a name that is closer to what the JavaScript really provides, from a functional point of view, what do you think? > > - Ludovic just suggested an improvement (for the next versions): let the user configure which existing field could be used in an existing class for retrieving geographical information, that could be interesting indeed, to be discussed. The calendar application works this way already as far as I understood: it lets the user define the date / time field to be used. > > Cheers > > Stéphane > > > Fawad Ali: > > Hi all, > > Hope everyone is well. > > > > Please review the application developed so far. I have included a UI test and map states. I think we should release the application as soon as we can so that user reviews can be gathered. > > > > Best, > > Fawad > -- Stéphane Laurière XWiki – https://xwiki.com
As a user, I like the Airbnb map experience with popups on top of the markers, what about you?
That is much like the default view of popups in Leaflet. This kind of popup supports very little information, that's why I made a dedicated space for popups. However, we could go with your suggestion of "view more". We could either open the parent page with "view more" or fill the search widget as you suggested. I would go with displaying more information in the search widget. Is that fine with you?
Along this line, another improvement (you probably have it in mind) would
be to introduce one or several dedicated sheets for such contextual information so that it can get easily customized by users with development skills.
I do not think this is required. If a developer wants a custom display for the popup information, he can create a class sheet and make pages with that sheet and it will become a map item after adding location object to the page.
Ok, we need to investigate this. I have a preliminary question about this
feature: how come that the URL does not reflect the mode status when hitting the full screen button the first time? I mean, if I'm not mistaken, when hitting the button before running any search, the URL remains unchanged, while the user may want to use that URL to share the map in full screen as is, or to embed it in full screen in a iframe, so shouldn't this parameter be present? Is there any difficulty with that? Wouldn't the facet widget reuse that URL afterwards? Sorry for any possible misunderstanding on my end.
I did not go with this flow because of better performance since a separate async request will be made for change in each state. What I am doing now is that I take the map state on search or other events that reload the map asynchronously.Thanks for your suggestion Stephane. I could update the page by observing a change in each state. This is a little slow because the map will have to be reloaded for each state but still a good option.
Best, Fawad
On Thu, Jul 11, 2019 at 3:26 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi all,
Hi all,
However, as a user I would expect the list to be present also whenthe 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 bedisplayed 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&qu...
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.136...
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 contrarilyto 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Fawad, all, > I have fixed the errors you mentioned. It appears one of thevariables 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 listof results anymore, and the search widget state is not restored.
> > > The list of results is just fine on my end, I am not sure whatcould be wrong.
In the meantime, I figured out that the list shows up indeed whenissuing 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. Sincefacets 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 Iwould 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 doesnot 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 forpotential 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 contrarilyto 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 nextversions): 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 thecalendar 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 <slauriere@xwiki.com mailto:slauriere@xwiki.com <mailto: slauriere@xwiki.com mailto:slauriere@xwiki.com>> wrote:
> > Hi Fawad, > > Good to hear from you again, I hope things are fine on yourend 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 withprevious version):
> > 2019-07-10 11:34:30,349 [http://ako:8090/xwiki-11.2/wiki/abraca/jsx/Maps/Code/Leaflet?language=en&...] 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&...] 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&...] 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&...] 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 alist of results anymore, and the search widget state is not restored.
> > - I notice there is no default radio button checked in thesearch 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 misleadingfor 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 nextversions): 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 haveincluded 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,
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 slauriere@xwiki.com wrote:
Fawad,
As a user, I like the Airbnb map experience with popups on top ofthe 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 aboutthis 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 m.fawaadali98@gmail.com 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 slauriere@xwiki.com wrote:
Fawad,
As a user, I like the Airbnb map experience with popups on top ofthe 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 questionabout 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 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 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 slauriere@xwiki.com 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, That's great news, congratulations for this first release!
Cheers
Stéphane
Hi all, Hope you are doing wonderful today.
I am very excited to announce that Interaction Maps Application v1.0 is now up.
Extension and documentation: https://extensions.xwiki.org/xwiki/bin/view/Extension/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
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 m.fawaadali98@gmail.com 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 slauriere@xwiki.com 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 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 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. 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.
I will start moving on with the development and create a mechanism for adding paths to the map.
Best, Fawad
On Wed, Jul 17, 2019 at 12:22 PM Vincent Massol vincent@massol.net wrote:
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 m.fawaadali98@gmail.com 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 slauriere@xwiki.com 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
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
On Mon, Jul 22, 2019 at 10:25 PM Stéphane Laurière slauriere@xwiki.com wrote:
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 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 slauriere@xwiki.com 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
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
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 <slauriere@xwiki.com mailto:slauriere@xwiki.com> 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,
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 slauriere@xwiki.com 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Fawad, I would go for approach C as well, that is storing all shape dataentirely 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 dealwith 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 allthe 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 ofeach 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 ineach 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
Stéphane,
Your suggestions regarding the Point Editor are also very helpful. I will make a sheet for PointClass as it will be much better. I will do the same with Shape Editor and ShapeClass as leaflet easily converts map items to GeoJSON.
Best, Fawad
On Thu, Aug 1, 2019 at 11:54 PM Fawad Ali m.fawaadali98@gmail.com wrote:
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 slauriere@xwiki.com 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 <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Fawad, I would go for approach C as well, that is storing all shape dataentirely 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 dealwith 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 allthe 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 ofeach 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 ineach 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
Stéphane, Ecaterina,
About the call, I think we should have it so that we all converge on the things to be done. However, tomorrow (Friday), I have a call with the Pakistan's GSoC community at about 5 PM UTC. If the call will be finished in two hours I am fine with it or we could reschedule it to 2:30 PM UTC or else Monday.
Best, Fawad
On Thu, Aug 1, 2019 at 11:58 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Stéphane,
Your suggestions regarding the Point Editor are also very helpful. I will make a sheet for PointClass as it will be much better. I will do the same with Shape Editor and ShapeClass as leaflet easily converts map items to GeoJSON.
Best, Fawad
On Thu, Aug 1, 2019 at 11:54 PM Fawad Ali m.fawaadali98@gmail.com wrote:
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 slauriere@xwiki.com 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 <
slauriere@xwiki.com mailto:slauriere@xwiki.com> wrote:
Hi Fawad, I would go for approach C as well, that is storing all shape dataentirely 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 dealwith 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 allthe 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 ofeach 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 ineach 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
Hi,
I am out of the country and won't have access to fast Internet in the following 2 weeks, so I won't be able to participate in the call. Sorry.
Caty
On Thu, Aug 1, 2019 at 10:03 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Stéphane, Ecaterina,
About the call, I think we should have it so that we all converge on the things to be done. However, tomorrow (Friday), I have a call with the Pakistan's GSoC community at about 5 PM UTC. If the call will be finished in two hours I am fine with it or we could reschedule it to 2:30 PM UTC or else Monday.
Best, Fawad
On Thu, Aug 1, 2019 at 11:58 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Stéphane,
Your suggestions regarding the Point Editor are also very helpful. I will make a sheet for PointClass as it will be much better. I will do the same with Shape Editor and ShapeClass as leaflet easily converts map items to GeoJSON.
Best, Fawad
On Thu, Aug 1, 2019 at 11:54 PM Fawad Ali m.fawaadali98@gmail.com wrote:
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 slauriere@xwiki.com 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 <
slauriere@xwiki.com mailto:slauriere@xwiki.com> wrote:
Hi Fawad, I would go for approach C as well, that is storing all shape dataentirely 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 dealwith 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, createall 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 valueof 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 ineach 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
Fawad,
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.
I created the museum-map-test branch in order to progress on this path, I hope this helps. In particular, imho, facets will be provided typically by objects from different classes than the geographical ones, such as a the Museum class (which very basic for now, it's just to expose the idea). My suggestion would be to progress toward an application that works well with a single sample facet + a full text input field + popups indeed + list + configurable icons and colors (typically one per facet value, I would say, so as for instance to represent all archeologia museums in a given color - even though we don't have that data yet, but we could use the countries all the same), and in parallel to gather more sample data with more facets and to progress toward having several configurable facets, what do you think?
Next, I will - Be working on making a dedicated space for popups inside or besides the map. Something similar to https://abc.gogocarto.fr 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.
Great
Cheers
Stéphane
Thanks, Fawad
Hi Fawad, Caty, all,
I just submitted some code to the interactive-maps repository that aims at a sample map with real data and facets (as a pull request, just to make sure we're in tune first, let me know). The code consists of the following:
- A Museum class with a single "country" property (string)
- A DataImporter script for converting Wikidata exported in JSON via a SPARQL query (that you can find in page Museums.WebHome) into XWiki pages consisting of a Museum object and a Point object.
- A simple map configuration for displaying the imported data
In order to configure the facets for this map, you'll have to add the following code to the top of the CommonMacros (if we go this way, we'll have to make this configurable at each map level):
{{velocity output="false"}} #set ($solrConfig = { 'filterQuery': [ 'type:DOCUMENT', 'class:Maps.Code.PointClass' ], 'facetFields': [ 'property.Maps.MapTesting.Museums.Code.MuseumClass.country_string' ] }) {{/velocity}}
Here's a capture of what I get on my side when selecting the "Spain" facet:
https://up1.xwikisas.com/#ZTkIQ8K1fXLrY5dgvp6BvA
Hoping such sample data can help developing further and think in greater details about real case scenarios. 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).
Cheers
Stéphane
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
Hi all, Hoping you a great week-end.
I am having trouble testing my application because of some dependencies. This is the POM: https://github.com/xwiki-contrib/application-interactive-maps/blob/master/ap...
Some of the leaflet dependencies are not being installed during testing. I am not sure why. When I open a page that uses leaflet libraries I get an error from requirejs that the library cannot be loaded. And there is no data when I go to the url generated by $services.webjars.url() which leads me to believe that the dependency is not being installed as an extension.
If I manually install the dependencies into my Wiki then it works fine.
Do you think there is something missing within the POM?
Best, Fawad
On Fri, Aug 23, 2019 at 2:42 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
On Sat, Aug 24, 2019, 17:04 Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hoping you a great week-end.
I am having trouble testing my application because of some dependencies. This is the POM: https://github.com/xwiki-contrib/application-interactive-maps/blob/master/ap...
Maybe the repositories are not found. Are the dependencies available from Maven Central? I see you have your own group id. Is that artifact published on any public repository or just local on your machine? Also, make sure you publish everything for the Google requirements.
Thanks, Caty
Some of the leaflet dependencies are not being installed during testing. I am not sure why. When I open a page that uses leaflet libraries I get an error from requirejs that the library cannot be loaded. And there is no data when I go to the url generated by $services.webjars.url() which leads me to believe that the dependency is not being installed as an extension.
If I manually install the dependencies into my Wiki then it works fine.
Do you think there is something missing within the POM?
Best, Fawad
On Fri, Aug 23, 2019 at 2:42 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
Hi Ecaterina, Good to see you, hope you are doing well.
Do you mean "org.webjars.bowergithub.9inpachi"? This is deployed on http://webjars.org I am not sure what could be wrong here. Even the leaflet dependency is not being installed in the latest tests. After installing Extension Manager Application into the test XWiki instance, I found that for Interactive Maps Application, the leaflet dependencies were labeled as "Provided" as opposed to "Installed" for other dependencies.
The tests started failing around this commit https://github.com/xwiki-contrib/application-interactive-maps/commit/e3163a2...
I added leaflet-indoor.js as an attachment temporarily while I was waiting for the one deployed on webjars.org to function properly. I did remove it later on and added as a dependency but that doesn't seem to have solved the problem. I feel like this is some issue with the test itself and since I haven't made any changes to the test, the test frameworks might have been updated. I don't really know the cause since all was working fine before this.
Best, Fawad
On Sun, Aug 25, 2019 at 1:39 AM Ecaterina Moraru (Valica) valicac@gmail.com wrote:
On Sat, Aug 24, 2019, 17:04 Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hoping you a great week-end.
I am having trouble testing my application because of some dependencies. This is the POM: https://github.com/xwiki-contrib/application-interactive-maps/blob/master/ap...
Maybe the repositories are not found. Are the dependencies available from Maven Central? I see you have your own group id. Is that artifact published on any public repository or just local on your machine? Also, make sure you publish everything for the Google requirements.
Thanks, Caty
Some of the leaflet dependencies are not being installed during testing. I am not sure why. When I open a page that uses leaflet libraries I get an error from requirejs that the library cannot be loaded. And there is no data when I go to the url generated by $services.webjars.url() which leads me to believe that the dependency is not being installed as an extension.
If I manually install the dependencies into my Wiki then it works fine.
Do you think there is something missing within the POM?
Best, Fawad
On Fri, Aug 23, 2019 at 2:42 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
Hi all, Hope you are all well.
Can I prepare my report on gist if that's all right? The current application page feels more like a progress then a report. I want to make the report minimal so that future readers can easily get the idea without having to dive too much into details. I will link all the necessary pages on the gist.
Best, Fawad
On Sun, Aug 25, 2019 at 1:49 AM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Ecaterina, Good to see you, hope you are doing well.
Do you mean "org.webjars.bowergithub.9inpachi"? This is deployed on http://webjars.org I am not sure what could be wrong here. Even the leaflet dependency is not being installed in the latest tests. After installing Extension Manager Application into the test XWiki instance, I found that for Interactive Maps Application, the leaflet dependencies were labeled as "Provided" as opposed to "Installed" for other dependencies.
The tests started failing around this commit https://github.com/xwiki-contrib/application-interactive-maps/commit/e3163a2...
I added leaflet-indoor.js as an attachment temporarily while I was waiting for the one deployed on webjars.org to function properly. I did remove it later on and added as a dependency but that doesn't seem to have solved the problem. I feel like this is some issue with the test itself and since I haven't made any changes to the test, the test frameworks might have been updated. I don't really know the cause since all was working fine before this.
Best, Fawad
On Sun, Aug 25, 2019 at 1:39 AM Ecaterina Moraru (Valica) < valicac@gmail.com> wrote:
On Sat, Aug 24, 2019, 17:04 Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hoping you a great week-end.
I am having trouble testing my application because of some dependencies. This is the POM: https://github.com/xwiki-contrib/application-interactive-maps/blob/master/ap...
Maybe the repositories are not found. Are the dependencies available from Maven Central? I see you have your own group id. Is that artifact published on any public repository or just local on your machine? Also, make sure you publish everything for the Google requirements.
Thanks, Caty
Some of the leaflet dependencies are not being installed during testing. I am not sure why. When I open a page that uses leaflet libraries I get an error from requirejs that the library cannot be loaded. And there is no data when I go to the url generated by $services.webjars.url() which leads me to believe that the dependency is not being installed as an extension.
If I manually install the dependencies into my Wiki then it works fine.
Do you think there is something missing within the POM?
Best, Fawad
On Fri, Aug 23, 2019 at 2:42 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
Fawad, can you make sure you've released the application on Contrib? I don't see a new version on GitHub or on e.x.o.
Thanks, Caty
On Sun, Aug 25, 2019 at 9:41 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hope you are all well.
Can I prepare my report on gist if that's all right? The current application page feels more like a progress then a report. I want to make the report minimal so that future readers can easily get the idea without having to dive too much into details. I will link all the necessary pages on the gist.
Best, Fawad
On Sun, Aug 25, 2019 at 1:49 AM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Ecaterina, Good to see you, hope you are doing well.
Do you mean "org.webjars.bowergithub.9inpachi"? This is deployed on http://webjars.org I am not sure what could be wrong here. Even the leaflet dependency is not being installed in the latest tests. After installing Extension Manager Application into the test XWiki instance, I found that for Interactive Maps Application, the leaflet dependencies were labeled as "Provided" as opposed to "Installed" for other dependencies.
The tests started failing around this commit https://github.com/xwiki-contrib/application-interactive-maps/commit/e3163a2...
I added leaflet-indoor.js as an attachment temporarily while I was waiting for the one deployed on webjars.org to function properly. I did remove it later on and added as a dependency but that doesn't seem to have solved the problem. I feel like this is some issue with the test itself and since I haven't made any changes to the test, the test frameworks might have been updated. I don't really know the cause since all was working fine before this.
Best, Fawad
On Sun, Aug 25, 2019 at 1:39 AM Ecaterina Moraru (Valica) < valicac@gmail.com> wrote:
On Sat, Aug 24, 2019, 17:04 Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hoping you a great week-end.
I am having trouble testing my application because of some dependencies. This is the POM: https://github.com/xwiki-contrib/application-interactive-maps/blob/master/ap...
Maybe the repositories are not found. Are the dependencies available from Maven Central? I see you have your own group id. Is that artifact published on any public repository or just local on your machine? Also, make sure you publish everything for the Google requirements.
Thanks, Caty
Some of the leaflet dependencies are not being installed during testing. I am not sure why. When I open a page that uses leaflet libraries I get an error from requirejs that the library cannot be loaded. And there is no data when I go to the url generated by $services.webjars.url() which leads me to believe that the dependency is not being installed as an extension.
If I manually install the dependencies into my Wiki then it works fine.
Do you think there is something missing within the POM?
Best, Fawad
On Fri, Aug 23, 2019 at 2:42 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
Hi Ecaterina, Hope you are well.
I was waiting for a complete review from Stephane. There are some issues that he brought forward today. The application will be released as soon as those issues are resolved.
Thanks, Fawad
On Sun, Sep 1, 2019, 6:59 PM Ecaterina Moraru (Valica) valicac@gmail.com wrote:
Fawad, can you make sure you've released the application on Contrib? I don't see a new version on GitHub or on e.x.o.
Thanks, Caty
On Sun, Aug 25, 2019 at 9:41 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hope you are all well.
Can I prepare my report on gist if that's all right? The current application page feels more like a progress then a report. I want to make the report minimal so that future readers can easily get the idea without having to dive too much into details. I will link all the necessary pages on the gist.
Best, Fawad
On Sun, Aug 25, 2019 at 1:49 AM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Ecaterina, Good to see you, hope you are doing well.
Do you mean "org.webjars.bowergithub.9inpachi"? This is deployed on http://webjars.org I am not sure what could be wrong here. Even the leaflet dependency is not being installed in the latest tests. After installing Extension Manager Application into the test XWiki instance, I found that for Interactive Maps Application, the leaflet dependencies were labeled as "Provided" as opposed to "Installed" for other dependencies.
The tests started failing around this commit https://github.com/xwiki-contrib/application-interactive-maps/commit/e3163a2...
I added leaflet-indoor.js as an attachment temporarily while I was waiting for the one deployed on webjars.org to function properly. I did remove it later on and added as a dependency but that doesn't seem to have solved the problem. I feel like this is some issue with the test itself and since I haven't made any changes to the test, the test frameworks might have been updated. I don't really know the cause since all was working fine before this.
Best, Fawad
On Sun, Aug 25, 2019 at 1:39 AM Ecaterina Moraru (Valica) < valicac@gmail.com> wrote:
On Sat, Aug 24, 2019, 17:04 Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hoping you a great week-end.
I am having trouble testing my application because of some dependencies. This is the POM: https://github.com/xwiki-contrib/application-interactive-maps/blob/master/ap...
Maybe the repositories are not found. Are the dependencies available from Maven Central? I see you have your own group id. Is that artifact published on any public repository or just local on your machine? Also, make sure you publish everything for the Google requirements.
Thanks, Caty
Some of the leaflet dependencies are not being installed during testing. I am not sure why. When I open a page that uses leaflet libraries I get an error from requirejs that the library cannot be loaded. And there is no data when I go to the url generated by $services.webjars.url() which leads me to believe that the dependency is not being installed as an extension.
If I manually install the dependencies into my Wiki then it works fine.
Do you think there is something missing within the POM?
Best, Fawad
On Fri, Aug 23, 2019 at 2:42 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière < slauriere@xwiki.com> wrote:
> Hi Fawad, Hi Caty, Hi all, > > Since the GSoC deadline for work submission is approaching, I'm > confident that all is in order for you Fawad but, also since it's my first > participatoin in the program, can I ask you to let us know what you plan to > publish, when and where, so that we make sure we're in tune and don't miss > any deadline or requirement? > > The reference page I'm aware of is the one below, do you have any > other? > > https://developers.google.com/open-source/gsoc/help/work-product > > Are we in tune? > > Cheers > > Stéphane > >
Hi Caty, Fawad, all,
There's been much progress on the app recently by Fawad, that's great, I spotted a few issues that are likely to block the release indeed, not many, most of the entries I created on Jira today are improvement suggestions for upcoming releases. The three key ones imho are:
- JavaScript instability on map at Demo.WebHome https://jira.xwiki.org/browse/INTMAP-76 – In case this is too long to fix, I'd suggest we remove the indoor feature from the demo for the release itself, so that we get a 100% working demo, what do you think? Obviously fixing it would be even better, let me know if you need help Fawad.
- Leaflet configuration issue on installation https://jira.xwiki.org/browse/INTMAP-74 – Removing the version number seems to work fine with all recent XWiki versions and matches the WebjarScriptService documentation, to be tested further, and we will need to investigate what fails with the continuous integration, but not a blocker issue imho.
- JSON format errors on map at Demo.WebHome https://jira.xwiki.org/browse/INTMAP-75
Fixing the overflow issue would be nice as well since it would enhance the first live contact of the user with the app: https://jira.xwiki.org/browse/INTMAP-85 – Unsetting the "overflow" rule of #xwikicontent fixes the issue but may introduce others. The Mozilla documentation page https://developer.mozilla.org/en-US/docs/Web/CSS/overflow states that "overflow" is useful only when a height is set or "white-space" set to "nowrap". I'm wondering in which cases the height of #xwikicontent needs to be set, or the "white-space" option. Do you have any idea Caty, all?
Cheers
Stéphane
Fawad Ali:
Hi Ecaterina, Hope you are well.
I was waiting for a complete review from Stephane. There are some issues that he brought forward today. The application will be released as soon as those issues are resolved.
Thanks, Fawad
On Sun, Sep 1, 2019, 6:59 PM Ecaterina Moraru (Valica) <valicac@gmail.com mailto:valicac@gmail.com> wrote:
Fawad, can you make sure you've released the application on Contrib? I don't see a new version on GitHub or on e.x.o. Thanks, Caty
Hi,
What I would like is a working version of the application that can be installed, as a final version that can be linked and showed the work done.
On Sun, Sep 1, 2019 at 5:48 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Caty, Fawad, all,
There's been much progress on the app recently by Fawad, that's great, I spotted a few issues that are likely to block the release indeed, not many, most of the entries I created on Jira today are improvement suggestions for upcoming releases. The three key ones imho are:
- JavaScript instability on map at Demo.WebHome
https://jira.xwiki.org/browse/INTMAP-76 – In case this is too long to fix, I'd suggest we remove the indoor feature from the demo for the release itself, so that we get a 100% working demo, what do you think? Obviously fixing it would be even better, let me know if you need help Fawad.
- Leaflet configuration issue on installation
https://jira.xwiki.org/browse/INTMAP-74 – Removing the version number seems to work fine with all recent XWiki versions and matches the WebjarScriptService documentation, to be tested further, and we will need to investigate what fails with the continuous integration, but not a blocker issue imho.
- JSON format errors on map at Demo.WebHome
https://jira.xwiki.org/browse/INTMAP-75
Fixing the overflow issue would be nice as well since it would enhance the first live contact of the user with the app: https://jira.xwiki.org/browse/INTMAP-85 – Unsetting the "overflow" rule of #xwikicontent fixes the issue but may introduce others. The Mozilla documentation page https://developer.mozilla.org/en-US/docs/Web/CSS/overflow states that "overflow" is useful only when a height is set or "white-space" set to "nowrap". I'm wondering in which cases the height of #xwikicontent needs to be set, or the "white-space" option. Do you have any idea Caty, all?
We should not remove the overflow from #xwikicontent. Make sure the map is clearing the floats, but I find the issue to be minor.
Thanks, Caty
Cheers
Stéphane
Fawad Ali:
Hi Ecaterina, Hope you are well.
I was waiting for a complete review from Stephane. There are some issues that he brought forward today. The application
will be released as soon as those issues are resolved.
Thanks, Fawad
On Sun, Sep 1, 2019, 6:59 PM Ecaterina Moraru (Valica) <
valicac@gmail.com mailto:valicac@gmail.com> wrote:
Fawad, can you make sure you've released the application on Contrib?I don't see a new version on GitHub or on e.x.o.
Thanks, Caty
Hi Stephane, Ecaterina and all,
I will try solving the key issues as soon as possible so we can move on with the release. It might take some time because my summer break is over and the University opens tomorrow. But I will make sure all of these are done soon.
Best, Fawad
On Sun, Sep 1, 2019 at 7:54 PM Ecaterina Moraru (Valica) valicac@gmail.com wrote:
Hi,
What I would like is a working version of the application that can be installed, as a final version that can be linked and showed the work done.
On Sun, Sep 1, 2019 at 5:48 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Caty, Fawad, all,
There's been much progress on the app recently by Fawad, that's great, I spotted a few issues that are likely to block the release indeed, not many, most of the entries I created on Jira today are improvement suggestions for upcoming releases. The three key ones imho are:
- JavaScript instability on map at Demo.WebHome
https://jira.xwiki.org/browse/INTMAP-76 – In case this is too long to fix, I'd suggest we remove the indoor feature from the demo for the release itself, so that we get a 100% working demo, what do you think? Obviously fixing it would be even better, let me know if you need help Fawad.
- Leaflet configuration issue on installation
https://jira.xwiki.org/browse/INTMAP-74 – Removing the version number seems to work fine with all recent XWiki versions and matches the WebjarScriptService documentation, to be tested further, and we will need to investigate what fails with the continuous integration, but not a blocker issue imho.
- JSON format errors on map at Demo.WebHome
https://jira.xwiki.org/browse/INTMAP-75
Fixing the overflow issue would be nice as well since it would enhance the first live contact of the user with the app: https://jira.xwiki.org/browse/INTMAP-85 – Unsetting the "overflow" rule of #xwikicontent fixes the issue but may introduce others. The Mozilla documentation page https://developer.mozilla.org/en-US/docs/Web/CSS/overflow states that "overflow" is useful only when a height is set or "white-space" set to "nowrap". I'm wondering in which cases the height of #xwikicontent needs to be set, or the "white-space" option. Do you have any idea Caty, all?
We should not remove the overflow from #xwikicontent. Make sure the map is clearing the floats, but I find the issue to be minor.
Thanks, Caty
Cheers
Stéphane
Fawad Ali:
Hi Ecaterina, Hope you are well.
I was waiting for a complete review from Stephane. There are some issues that he brought forward today. The application
will be released as soon as those issues are resolved.
Thanks, Fawad
On Sun, Sep 1, 2019, 6:59 PM Ecaterina Moraru (Valica) <
valicac@gmail.com mailto:valicac@gmail.com> wrote:
Fawad, can you make sure you've released the application onContrib? I don't see a new version on GitHub or on e.x.o.
Thanks, Caty
Hi Fawad,
Thank you for letting us know. I hope your new university session tomorrow will meet your expectations and I wish you a great training year ahead.
I don't want to add complexity to the process so I'm not touching anything in the code, but I'm at your disposal for any help or any code contributions you'd like to get toward the 1.1 release.
Thumbs up for your involvement in the project and good luck with the steps of this Google Summer of Code,
Stéphane
Hi Stephane, Ecaterina and all,
I will try solving the key issues as soon as possible so we can move on with the release. It might take some time because my summer break is over and the University opens tomorrow. But I will make sure all of these are done soon.
Best, Fawad
Caty, Fawad, all,
Hi,
What I would like is a working version of the application that can be installed, as a final version that can be linked and showed the work done.
Indeed, it'd be a cool achievement.
On Sun, Sep 1, 2019 at 5:48 PM Stéphane Laurière <slauriere@xwiki.com mailto:slauriere@xwiki.com> wrote:
Hi Caty, Fawad, all, There's been much progress on the app recently by Fawad, that's great, I spotted a few issues that are likely to block the release indeed, not many, most of the entries I created on Jira today are improvement suggestions for upcoming releases. The three key ones imho are: - JavaScript instability on map at Demo.WebHome https://jira.xwiki.org/browse/INTMAP-76 – In case this is too long to fix, I'd suggest we remove the indoor feature from the demo for the release itself, so that we get a 100% working demo, what do you think? Obviously fixing it would be even better, let me know if you need help Fawad. - Leaflet configuration issue on installation https://jira.xwiki.org/browse/INTMAP-74 – Removing the version number seems to work fine with all recent XWiki versions and matches the WebjarScriptService documentation, to be tested further, and we will need to investigate what fails with the continuous integration, but not a blocker issue imho. - JSON format errors on map at Demo.WebHome https://jira.xwiki.org/browse/INTMAP-75 Fixing the overflow issue would be nice as well since it would enhance the first live contact of the user with the app: https://jira.xwiki.org/browse/INTMAP-85 – Unsetting the "overflow" rule of #xwikicontent fixes the issue but may introduce others. The Mozilla documentation page https://developer.mozilla.org/en-US/docs/Web/CSS/overflow states that "overflow" is useful only when a height is set or "white-space" set to "nowrap". I'm wondering in which cases the height of #xwikicontent needs to be set, or the "white-space" option. Do you have any idea Caty, all?We should not remove the overflow from #xwikicontent. Make sure the map is clearing the floats, but I find the issue to be minor.
Sure, we don't want to remove the overflow, I was just wondering about its exact role. I'm convinced it's there for a good reason. I also agree with you the issue is minor. Thanks for your suggestion about clearing the float, I gave it a try with no luck so far but I'm for from having a deep understanding of CSS, just a humble admirer
Chees
Stéphane
Hi all, Hope you are doing good.
I just received the mail from Google for the final evaluations. Thanks for all the kind words. It is an absolutely wonderful experience to work on this project!
Regarding the release, I would like to inform you that the documentation for releasing the second version was actually prepared during the GSoC period. Due to several unprecedented issues like the leaflet webjar not loading up (even with no change in dependencies) the release was postponed as opposed to my plan to release the application on the last day of GSoC. After that, several issues were opened by Stephane. It is a mistake on my part for not taking these unprecedented circumstances into account but the release will surely be done sometime around this week.
Thanks, Fawad
On Sun, Sep 1, 2019 at 10:51 PM Stéphane Laurière slauriere@xwiki.com wrote:
Caty, Fawad, all,
Hi,
What I would like is a working version of the application that can be
installed, as a final version that can be linked and showed the work done.
Indeed, it'd be a cool achievement.
On Sun, Sep 1, 2019 at 5:48 PM Stéphane Laurière <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Caty, Fawad, all, There's been much progress on the app recently by Fawad, that'sgreat, I spotted a few issues that are likely to block the release indeed, not many, most of the entries I created on Jira today are improvement suggestions for upcoming releases. The three key ones imho are:
- JavaScript instability on map at Demo.WebHomehttps://jira.xwiki.org/browse/INTMAP-76 – In case this is too long to fix, I'd suggest we remove the indoor feature from the demo for the release itself, so that we get a 100% working demo, what do you think? Obviously fixing it would be even better, let me know if you need help Fawad.
- Leaflet configuration issue on installationhttps://jira.xwiki.org/browse/INTMAP-74 – Removing the version number seems to work fine with all recent XWiki versions and matches the WebjarScriptService documentation, to be tested further, and we will need to investigate what fails with the continuous integration, but not a blocker issue imho.
- JSON format errors on map at Demo.WebHomehttps://jira.xwiki.org/browse/INTMAP-75
Fixing the overflow issue would be nice as well since it wouldenhance the first live contact of the user with the app: https://jira.xwiki.org/browse/INTMAP-85 – Unsetting the "overflow" rule of #xwikicontent fixes the issue but may introduce others. The Mozilla documentation page https://developer.mozilla.org/en-US/docs/Web/CSS/overflow states that "overflow" is useful only when a height is set or "white-space" set to "nowrap". I'm wondering in which cases the height of #xwikicontent needs to be set, or the "white-space" option. Do you have any idea Caty, all?
We should not remove the overflow from #xwikicontent. Make sure the map
is clearing the floats, but I find the issue to be minor.
Sure, we don't want to remove the overflow, I was just wondering about its exact role. I'm convinced it's there for a good reason. I also agree with you the issue is minor. Thanks for your suggestion about clearing the float, I gave it a try with no luck so far but I'm for from having a deep understanding of CSS, just a humble admirer
Chees
Stéphane
Hi Fawad,
Thank you also for your hard work and I'm glad you had a nice time during GSOC.
Thanks also for providing some status and I will be waiting to install the latest version and see the feedback the others community members will have.
Caty
On Tue, Sep 3, 2019 at 9:28 PM Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all, Hope you are doing good.
I just received the mail from Google for the final evaluations. Thanks for all the kind words. It is an absolutely wonderful experience to work on this project!
Regarding the release, I would like to inform you that the documentation for releasing the second version was actually prepared during the GSoC period. Due to several unprecedented issues like the leaflet webjar not loading up (even with no change in dependencies) the release was postponed as opposed to my plan to release the application on the last day of GSoC. After that, several issues were opened by Stephane. It is a mistake on my part for not taking these unprecedented circumstances into account but the release will surely be done sometime around this week.
Thanks, Fawad
On Sun, Sep 1, 2019 at 10:51 PM Stéphane Laurière slauriere@xwiki.com wrote:
Caty, Fawad, all,
Hi,
What I would like is a working version of the application that can be
installed, as a final version that can be linked and showed the work done.
Indeed, it'd be a cool achievement.
On Sun, Sep 1, 2019 at 5:48 PM Stéphane Laurière <slauriere@xwiki.com
mailto:slauriere@xwiki.com> wrote:
Hi Caty, Fawad, all, There's been much progress on the app recently by Fawad, that'sgreat, I spotted a few issues that are likely to block the release indeed, not many, most of the entries I created on Jira today are improvement suggestions for upcoming releases. The three key ones imho are:
- JavaScript instability on map at Demo.WebHomehttps://jira.xwiki.org/browse/INTMAP-76 – In case this is too long to fix, I'd suggest we remove the indoor feature from the demo for the release itself, so that we get a 100% working demo, what do you think? Obviously fixing it would be even better, let me know if you need help Fawad.
- Leaflet configuration issue on installationhttps://jira.xwiki.org/browse/INTMAP-74 – Removing the version number seems to work fine with all recent XWiki versions and matches the WebjarScriptService documentation, to be tested further, and we will need to investigate what fails with the continuous integration, but not a blocker issue imho.
- JSON format errors on map at Demo.WebHomehttps://jira.xwiki.org/browse/INTMAP-75
Fixing the overflow issue would be nice as well since it wouldenhance the first live contact of the user with the app: https://jira.xwiki.org/browse/INTMAP-85 – Unsetting the "overflow" rule of #xwikicontent fixes the issue but may introduce others. The Mozilla documentation page https://developer.mozilla.org/en-US/docs/Web/CSS/overflow states that "overflow" is useful only when a height is set or "white-space" set to "nowrap". I'm wondering in which cases the height of #xwikicontent needs to be set, or the "white-space" option. Do you have any idea Caty, all?
We should not remove the overflow from #xwikicontent. Make sure the map
is clearing the floats, but I find the issue to be minor.
Sure, we don't want to remove the overflow, I was just wondering about its exact role. I'm convinced it's there for a good reason. I also agree with you the issue is minor. Thanks for your suggestion about clearing the float, I gave it a try with no luck so far but I'm for from having a deep understanding of CSS, just a humble admirer
Chees
Stéphane
Yes, thumbs up for your involvement, Fawad.
Collaborative maps have been burgeoning in many places in the last years, I'm optimistic about the fact taat the app paves the way for nice usages ahead.
Regarding the review, bear in mind that part of the exercise consisted in scratching our head to find some aspects that could get considered as recommendations for improvement :-). I owe you an apology for testing the latest version late in the process.
Good luck with the 1.1 release,
Cheers
Stéphane
Ecaterina Moraru (Valica):
Hi Fawad,
Thank you also for your hard work and I'm glad you had a nice time during GSOC.
Thanks also for providing some status and I will be waiting to install the latest version and see the feedback the others community members will have.
Caty
On Tue, Sep 3, 2019 at 9:28 PM Fawad Ali <m.fawaadali98@gmail.com mailto:m.fawaadali98@gmail.com> wrote:
Hi all, Hope you are doing good. I just received the mail from Google for the final evaluations. Thanks for all the kind words. It is an absolutely wonderful experience to work on this project! Regarding the release, I would like to inform you that the documentation for releasing the second version was actually prepared during the GSoC period. Due to several unprecedented issues like the leaflet webjar not loading up (even with no change in dependencies) the release was postponed as opposed to my plan to release the application on the last day of GSoC. After that, several issues were opened by Stephane. It is a mistake on my part for not taking these unprecedented circumstances into account but the release will surely be done sometime around this week. Thanks, Fawad
Hi all,
All the key issues pointed out by Stephane are fixed. Should we move on to release the application?
Best, Fawad
On Wed, Sep 4, 2019 at 1:39 PM Stéphane Laurière slauriere@xwiki.com wrote:
Yes, thumbs up for your involvement, Fawad.
Collaborative maps have been burgeoning in many places in the last years, I'm optimistic about the fact taat the app paves the way for nice usages ahead.
Regarding the review, bear in mind that part of the exercise consisted in scratching our head to find some aspects that could get considered as recommendations for improvement :-). I owe you an apology for testing the latest version late in the process.
Good luck with the 1.1 release,
Cheers
Stéphane
Ecaterina Moraru (Valica):
Hi Fawad,
Thank you also for your hard work and I'm glad you had a nice time
during GSOC.
Thanks also for providing some status and I will be waiting to install
the latest version and see the feedback the others community members will have.
Caty
On Tue, Sep 3, 2019 at 9:28 PM Fawad Ali <m.fawaadali98@gmail.com
mailto:m.fawaadali98@gmail.com> wrote:
Hi all, Hope you are doing good. I just received the mail from Google for the final evaluations.Thanks for all the kind words. It is an absolutely wonderful experience to work on this project!
Regarding the release, I would like to inform you that thedocumentation for releasing the second version was actually prepared during the GSoC period. Due to several unprecedented issues like the leaflet webjar not loading up (even with no change in dependencies) the release was postponed as opposed to my plan to release the application on the last day of GSoC. After that, several issues were opened by Stephane. It is a mistake on my part for not taking these unprecedented circumstances into account but the release will surely be done sometime around this week.
Thanks, Fawad
Yes, please do :)
Thanks, Caty
On Wed, Sep 4, 2019, 14:13 Fawad Ali m.fawaadali98@gmail.com wrote:
Hi all,
All the key issues pointed out by Stephane are fixed. Should we move on to release the application?
Best, Fawad
On Wed, Sep 4, 2019 at 1:39 PM Stéphane Laurière slauriere@xwiki.com wrote:
Yes, thumbs up for your involvement, Fawad.
Collaborative maps have been burgeoning in many places in the last years, I'm optimistic about the fact taat the app paves the way for nice usages ahead.
Regarding the review, bear in mind that part of the exercise consisted in scratching our head to find some aspects that could get considered as recommendations for improvement :-). I owe you an apology for testing the latest version late in the process.
Good luck with the 1.1 release,
Cheers
Stéphane
Ecaterina Moraru (Valica):
Hi Fawad,
Thank you also for your hard work and I'm glad you had a nice time
during GSOC.
Thanks also for providing some status and I will be waiting to install
the latest version and see the feedback the others community members will have.
Caty
On Tue, Sep 3, 2019 at 9:28 PM Fawad Ali <m.fawaadali98@gmail.com
mailto:m.fawaadali98@gmail.com> wrote:
Hi all, Hope you are doing good. I just received the mail from Google for the final evaluations.Thanks for all the kind words. It is an absolutely wonderful experience to work on this project!
Regarding the release, I would like to inform you that thedocumentation for releasing the second version was actually prepared during the GSoC period. Due to several unprecedented issues like the leaflet webjar not loading up (even with no change in dependencies) the release was postponed as opposed to my plan to release the application on the last day of GSoC. After that, several issues were opened by Stephane. It is a mistake on my part for not taking these unprecedented circumstances into account but the release will surely be done sometime around this week.
Thanks, Fawad
Hi Fawad, Caty, hi all,
I tested the latest version on my side and the fix work fine with me as well, that's cool, so Fawad I'd say also that you can go ahead with the release indeed.
Cheers
Stéphane
Ecaterina Moraru (Valica):
Yes, please do :)
Thanks, Caty
On Wed, Sep 4, 2019, 14:13 Fawad Ali <m.fawaadali98@gmail.com mailto:m.fawaadali98@gmail.com> wrote:
Hi all, All the key issues pointed out by Stephane are fixed. Should we move on to release the application? Best, Fawad
On Fri, Aug 23, 2019, 12:43 Fawad Ali m.fawaadali98@gmail.com wrote:
Hi Stéphane, Ecaterina, all,
Stephane, this is the report that I mentioned before. According to XWiki standards, what I plan to submit is a report based on the format documented at https://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/DocumentingStudentPr... . I updated this work progress halfway so half of it has to be done still but I am positive I will be able to do it well before time. The reason I chose to focus on the daily progress is that it gives more insight to the daily activities performed on the project and the report can be fairly easily created with using the daily progress as a reference.
I have no preference regarding the progress report. It depends also on the student's preference. The main purpose is that the mentors know the evolution if the project.
Thanks, Caty
If you have any other specific formats that you think will be better then please let me know, we can follow that as well.
Best, Fawad
On Fri, Aug 23, 2019 at 1:52 PM Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Cheers
Stéphane
On Fri, Aug 23, 2019, 11:52 Stéphane Laurière slauriere@xwiki.com wrote:
Hi Fawad, Hi Caty, Hi all,
Since the GSoC deadline for work submission is approaching, I'm confident that all is in order for you Fawad but, also since it's my first participatoin in the program, can I ask you to let us know what you plan to publish, when and where, so that we make sure we're in tune and don't miss any deadline or requirement?
The reference page I'm aware of is the one below, do you have any other?
https://developers.google.com/open-source/gsoc/help/work-product
Are we in tune?
Hi,
Fawad should follow the instructions given by Google, since they aldo need copies / links to the produced code.
Regarding XWiki's expectations, having the code public available on GitHub and released on Contrib / extensions.xwiki.org is enought.
Thanks, Caty
Cheers
Stéphane
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Fawad Ali -
Stéphane Laurière -
Thomas Mortagne -
Vincent Massol