CartoDB / cartoframes

CARTO Python package for data scientists
BSD 3-Clause "New" or "Revised" License
251 stars 63 forks source link

[Doc - Guides] Add Quickstart Guide #966

Closed elenatorro closed 4 years ago

elenatorro commented 5 years ago

Related with: Documentation Refactor EPIC

Context

The Quickstart guide should be a simple example that contains the main concepts we want to show to the first time users at a glance.

Current Status

We've decided to split the Quickstart Guide into 2 parts:

  1. In the first part, we'll read data from different sources and we'll create a visualization using a helper method

  2. In the second part, we'll use the data observatory and the data enrichment

This is currently blocked by https://github.com/CartoDB/cartoframes/pull/1083, cause the polygons enrichment method is failing and we need this PR to be merged to continue with this task.

makella commented 5 years ago

hi @elenatorro and @LadyAga! figured I'd bring the conversation about the Quickstart Guide over here!

from the doc:

question here: for the quickstart, should we go straight to the helper instead of adding all things, removing them, and then using a helper? alternatively, we could put the helper step after the "analysis with PySAL" and visualize that layer with a helper

Yesterday we discussed with +elena@cartodb.com that it would be better to avoid using Helpers in this Quickstart guide (to keep it as simple as possible). What are your thoughts on this, +makella@cartodb.com?

I can see this both ways and wanted to discuss that a little more!

in my mind, helpers are meant to be a quick start for visualizations (that include widgets, popups, etc.). so I worry that diving into some of the details like this in the Quickstart will make CF feel intimidating.

On the other hand, current helpers are most useful if you want to create a data-driven visualization. The other way of seeing it is that we are missing just a default_layer helper where you aren't styling on an attribute but instead have a dataset that you want to explore and be able to add a widget , a legend, popups, etc. We have all the pieces to put that kind of default layer helper together and i'm wondering if we should think about adding something like that? I see where the complications will arise in enabling the option to choose the value for each (for example, during the exploratory phase you may want to add a category widget on one field and a histogram widget on another similarly the legend, etc.)

For me, going straight to the legends, widgets, and popups at the layer level and then styling the final map with VL syntax, in the Quickstart, wouldn't demonstrate how "easy" we've made things! And this is a place where I'm guessing a lot of people will start.

Since the default_layer idea would be additional work, here is an idea for an alternate outline:

Again, this is just another take on the same thing and I think this workflow would be less complex, but look forward to discussing our options!

newLadyAga commented 5 years ago

Hi @makella! Thank you for sharing your thoughts! It's very useful to read them!

I worry that diving into some of the details like this in the Quickstart will make CF feel intimidating.

I worry as well. For me, the Quickstart guide should be a simple example that contains the main concepts we want to show to the first time users at a glance. The goal is to allow them to gain a solid insight into CARTOframes and how to achieve basic tasks.

For me, going straight [...] wouldn't demonstrate how "easy" we've made things!

I understand what you mean, but I would prefer to go to a schematic but meaningful example in which we cover each main step (explore, enrich, analyze and share) as straightforwardly as possible. Assuming it's a first entry point where we won't be able to show the full value of the library but only welcome and encourage users to learn more.

We have all the pieces to put that kind of default layer helper together and i'm wondering if we should think about adding something like that?

I like your approach, but also think it would be better to use the most obvious methods so that users can easily understand what a specific function does.

Here is an idea for an alternate outline

I really like it!

The only thing that came up in a previous conversation with @cmongut was about how to handle the Analysis step, so let's talk about it to decide on the best way forward.

Thank you!