Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement "reasonable defaults" depending on graph size and shape #116

Open
pstutz opened this issue May 22, 2013 · 11 comments
Open

Implement "reasonable defaults" depending on graph size and shape #116

pstutz opened this issue May 22, 2013 · 11 comments

Comments

@pstutz
Copy link
Member

pstutz commented May 22, 2013

It would be nice if the defaults used in the Console would depend on what the graph looks like. For example, for small graphs (<=500) vertices, the vertex count could be set to the number of vertices, so that the entire graph is shown by default.

@cshapeshifter
Copy link
Contributor

What do you mean by this? Explain it where? What do you mean by "enabling"? The tour in the Console has the following instructions in step 4:

"Exposing vertex details allows you to view any information a vertex is exposing through its 'expose' function"

The Inspectable code is commented now (closing #112), so the programmer should also have enough information. There is nothing to "enable". You can call expose() on any Vertex that implements Inspectable, and this is now documented in Inspectable. Is this sufficient?

@pstutz
Copy link
Member Author

pstutz commented May 22, 2013

Thanks, found it.

Sorry, I should have done the tour again. Is there a good reason not to enable the feature by default?

@pstutz
Copy link
Member Author

pstutz commented May 22, 2013

Maybe one could move the less often used options to an 'Advanced' or 'Performance' tab at the bottom that is collapsed by default. The 'Add and remove vertices from the canvas' tab is now cluttered with many options that do not seem directly relevant to adding or removing vertices.

@cshapeshifter
Copy link
Contributor

Well, it significantly slows down the graph loading speed and since the idea is that the user implements the 'expose' function on their vertex implementations, it's a liability. I.e. it could be very slow and the user should be aware of the conscious choice of enabling it. At least that was my thinking.
It's still fast though... It could be enabled by default and disabled only for really large graphs.

What less often used options do you have in mind? The options that don't directly add or remove options are already grouped in the very first section "options affecting performance".

@pstutz
Copy link
Member Author

pstutz commented May 22, 2013

Is the performance really affected that much?

As a personal preference I like reasonable defaults and would probably hide away options that you would not expect to be used often.

@pstutz
Copy link
Member Author

pstutz commented May 22, 2013

I agree that the reasonable defaults differ a lot between small and large graphs.

How about determining the graph size first and choosing defaults based on that?

@pstutz
Copy link
Member Author

pstutz commented May 22, 2013

Maybe there could be a switch and a message in case a large graph is detected. This way the process would not be so magical to the user.

@pstutz
Copy link
Member Author

pstutz commented May 22, 2013

Or have a simple switch between the large/small defaults and hide all the advanced stuff.

@pstutz
Copy link
Member Author

pstutz commented May 22, 2013

On an unrelated note: Using the console on multiple machines at the same time works impressively well. It's amazing!

@cshapeshifter
Copy link
Contributor

I've enabled the vertex details by default now. But I suppose implementing a "reasonable defaults depending on graph topology" strategy is low priority. I'm leaving this issue open for future generations ;-)

@cshapeshifter
Copy link
Contributor

Renamed the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants