algolia / places Goto Github PK

One thing reac website does well is the header. Even on big screens.

It's easy to go from page to page and to go back to home

While for us, currently, on a big screen, the left part is realllllly far from the right part while. And both parts are really far from the actual content. So if we track mouse moves, we will see people travelling a lot to get/follow/click.

What do you think?

Need algolia/autocomplete#63 first to be done.

Hey guys @vvo @LukyVj , few remarks based on what we can see on community.algolia.com/places

Header

Related to what Vincent said on the header for large screen, it's a good idea to limit it size with something like max-width: 1400px but on small/normal screen, we shouldn't limit that with our 960px grid.

• Header max-width: 1400px
• Do not put but by default the pipe + Places, maybe use it only when scrolling + on documentation

Hero Banner

• Align title block (left) with the illustration (right) — c.f alignment
• Add more white space between the head and the container in the hero banner
• Increase the space between the dash under Algolia mark and the title

Before

After

What about changing the sentence :

To use Algolia Places, you only need an HTML and the places.js library. It takes 1 minute to install it on your website.

with

To use Algolia Places, you only need to add an HTML and the places.js library. It takes 1 minute to install it on your website.

Before:

After :

Lets imagine Algolia Places get used on a Restaurant booking platform. Then AlgoliaPlaces will probably be used on the main page so people can search for restaurant by location - which is great.
But they also may want to add search results for their Restaurants, Restaurants' categories, ...

Would be nice to provide our user with an easy way to do that.

It's because event is not defined.

With the current styling, it's super complex to understand results:

On the landing page, when you try the demo input, the Json response is not showing up anymore.

autocomplete.js should be able to display a hint for the top suggestion inside the input.

Something like this:

But it's not

related to #46

Hey guys @vvo @LukyVj , few remarks based on what we can see on places/documentation

Header

Can we keep the same style we're using on Instant Search?

.navigation ul li {
    padding: 0 15px;
    font-family: "Open Sans";
    font-size: 14px;
    text-transform: capitalize;
    padding-bottom: 19px;
}

.navigation ul li.active a {
    border-bottom: 3px solid #fb366e;
    padding-bottom: 18px;
}

Hero Banner

• Align the title block with the illustration
• Increase the space between the dash and the title

Documentation

• Start the vertical divide line next after the hero banner
• Align both Getting Started
• Add by default active style on Getting Started

Before

After

Current header can easily be understood as "This is the Algolia Community website" not "This is the Algolia Places website, which is part of Algolia Community"

Could be nice to have the sub items showing not just the h2 but also h3. Because otherwise the sidebar looks very tiny :)

On a styling side, I wasn't able to quickly hack sublists styling, it failed.

Another language is matching:

The locale_name is multi-valued, and we only display city[0]

no big deal for now, just quit screen

dunno why

When clicking on the sidebar, it should:

• mark the element as active with the right styling
• mark the documentation right header (h2, h3) as active with the right styling

When hovering a header, we should display a clickable "#" much like http://facebook.github.io/react/docs/getting-started.html. It's already done, but it needs to be styled with the right color

https://s.adroll.comj/roundtrip.js does not exists

As said on the #places channel, I can see a strange bug on the left menu, on the documentation and the examples.

If I start to scroll, the menu got directly hidden.

As far as I read the code, it seems that it's caused by this file & line :

I prefer asking before doing anything. Since it seems to be working with all of you guys, and the bug occurs only on my end. ( on both local & https://community.algolia.com/places )

I'm getting a 403 forbidden on the main script

Safari 9.1

I feel like since we are building for both NPM and <script> users, we should just inline the CSS, there's no more need to have it as an external dependency.

Places should be a "drop this JS annnd it works" type, what do you think?

As mentionned in #81

• Add by default .active style on Getting Started

• iPhone / Smartphones :
  • Rework the hero-header sizes and content alignment to make it "visually balanced"
  • Align badges on the marketing-section
  • Rework the footer to make all buttons fitting in it
• iPad / Tablets :
  • Pull up the badges of the marketing section
• General on handled devices
  • Only set the #sidebar links active when the sidebar is in .fixed state.
  • Review some font-sizes
  • Align the "Algolia logo" on the header

When selecting the text inside the input in firefox, the selection background is invisible. The behavior is correct on docsearch community website it seems: https://community.algolia.com/docsearch/

We could even imagine to perform a first search request at page loading to retrieve the big cities around the current user’s location and then use those N top location to populate a dynamic placeholder
=> so everyone would have a different one.

The small algolia stopwatch logo is not clickable and A bit strange => if it was clickable I would expect it to go back to the places homepage.

What do you think?

See:

At the end, when the focus is not on the search input, the full address is added to the input, when it should stay at "88 rue de Rivoli"

There is a bug regarding the titles on mobile :

After a fix :

The left menu does not update when I'm scrolling, neither is the URL.
Also, if you click an anchor (#) next to a title, the URL changes, but not the highlighting on the menu.

The CSS got changed somehow and now the layout of the documentation needs some fixes.

Let's add the

<script src="//cdn.jsdelivr.net/places.js/0/places.min.js"></script>

to every example, so we can simply copy/paste without having to go the Doc page to get them working.

Step to reproduce:

• fill in the autocomplete
• select a place
• empty the input field

The event then contains only the query attribute {query:""}. At the very least, the documentation should indicate that not all the attributes of the event are present at all time, and should give some context. But another event for empty results could be more practical.

Strangely, and maybe related to #29, the autocomplete text cursor is not blinking:

When the user types a query, the right pin in the searchbox should turn into a cross that when clicked should empty the input.

This must be done in JS most probably because a simple <button type="reset"> will not cut it: we do not own nor know if the input will be in a form nor if it will be the only input in the form.

Thus we will need to do it with JS, programmatically setting the query of the autocomplete.js instance.

npm run dev

• provides the places/ website with auto reload on docs and actual places autocomplete library

On a wide screen, the marketing section background shouldn't behave like this :

Due to the fixed header bar

https://community.algolia.com/places/documentation.html#setup

I put a demo webpage at /nostyle.html where we can see that the default styling of places.scss is not yet very consistent.

We may need to add box shadow by default in the default style and then using #91 we will disable custom styling where needed.

@redox Said :

guys are we able to use fixed-width SVG icons? I think it will make things better, right?

once almost good

We want to show that Algolia Places and autocomplete.js are compatible.

And that you can easily build an autocompletion menu mixing Algolia Places results along with other indices.

Luckily, autocomplete.js has the concept of sources, this is actually what we are using in places.js.

Places.js is only a wrapper around autocomplete.js. Now we would like to make it a wrapper AND also it should expose a way for autocomplete.js to show places results.

For this, we do not want to duplicate code or insert too much things in the autocomplete.js build. So the goal would be to build a places autocomplete.js source and distribute it in places.js.

Overview of the needed steps:

• extract the formatting and query building of places.js into places/src/createAutocompleteSource.js
• createAutocompleteSource should read all the places.js parameters and build an autocomplete.js source ready to use
• places/src/places.js should just be about forwarding options to places/src/createAutocompleteSource.js and get a ready to use autocomplete.js source back
• there should be a build step to create dist/autocomplete.sources.places.js which would attach itself to the autocomplete.js export at autocomplete.sources.places API endpoint

Then any npm user or any script user will be able to either use places/src/createAutocompleteSource.js or the jsDelivr places sources build with autocomplete.js.

One can use the autocomplete.js npm run dev and npm link commands to quickly iterate on this.

The default behaviour has an usability issue: when you hover result, it overrides what you were typing for. See:

The content shouldn't be overwritten before the user specifically clicks on it.

In order to easily integrate on an existing website with a lot of custom styling around inputs, we should be able to use places.js without the whole CSS places.js is injecting.

This would mean exposing an option to have a places.js without styling around borders, shadows, border-radius, paddings, margins.

Should we just load 0 CSS at all? Because if we start doing half CSS half no CSS then people might have a hard time removing the last bits.

Only issue about this are the icons, pin, clear and city icons both in the input and in the dropdown are stylised.

Otherwise, we will expose in a second step ways to override SVG icons.

Implentation wise, this would mean using the nice options on css.use() of our webpack style loader: https://github.com/webpack/style-loader#reference-counted-api

We can split in:

• core.scss => always injected, may contain the pin/clear icons well positionned
• places.scss => always injected BUT if noStyle: true passed

I wonder if the default behavior should be to load the places.scss or to make it on demand. Maybe the later the better.