0

Tags Field + "Dashboard" pages

Pliny (John Eremic)

July 14, 2009 15:39

None

Follow

I was going to request a "Tags" field type, then I stumbled across it.  Already exists.  Cool.

Now here's one way I'd like to use this.  I currently keep track of my daily team meeting agenda in a text editor.  What would be much cooler: if I could flag any item in SG--a note, a task, etc.--with the "agenda" tag.  That way I could constantly building tomorrow's meeting agenda throughout the day.  Very handy.

What prevents me from doing this is that I cannot build a single view that aggregates different types of entities on one page.  So yes, I am backing into the old "flexible Dashboard view" feature request.  Instead of widgets however, I would imagine this as a more standard list view, listing entries from different entities on a single page.

This would be a challenge since different entities have different fields.  But you could at least display a "primary key" (code) column, along with common fields, such as "Description" or "Status", which could conceivably co-exist in a single table.

Thoughts?

• Facebook
• Twitter
• LinkedIn

5 comments

• 0
  
  KP July 15, 2009 19:24

  Interesting. Definitely can see the usefulness of this and you're right, at first glance the query options could be limiting, or also very complicated if you wanted to do something that did query on entity-specific fields for a particular entity type. We will be looking more at cross-entity searches when we work on global searching within Shotgun and it seems like this challenge is related.

  What other kinds of cross-entity type queries would you be interested in? Anyone else have use cases we can look at?

• 0
  
  Pliny (John Eremic) July 15, 2009 21:42

  As an alternative to cross-entity queries populating a single table, we could also think about putting multiple tables on the same page -- kind of like dashboard widgets function now (although they only pull from a single entity, "Project").

• 0
  
  Don Parker July 16, 2009 07:28

  Pliny, what if you could have multiple grids on a page, each that could open and shut, each with their own entity and layout options and queries.  Would that work for you?

• 0
  
  Don Parker July 16, 2009 07:33

  Oops, I guess what I said is what you said.  That's the approach we're going to take first for our Dashboard pages, so this sounds like another use for that tool.

• 0
  
  Pliny (John Eremic) July 16, 2009 15:35

  Yup - I see value in both.

  Right now I have a number of views now that throw "alerts" when something is not as it should be.  Orphan tasks, overdue tasks, jobs past their due date to start/end, etc.  Here I could make use of a flexible multi-grid page instead of having to click through a bunch of pages.

  On the other hand, the initial scenario described (search all entities for tags) would benefit from the single cross-entity table concept. For example, the table could just have two columns: code and status.  Most if not all entities have these fields.  The cross-entity query would simply matched on field name, and it would be up to the admin to enforce consistency in field naming.

  in some cases, an entity might not have the field in question: those cells could be assigned a color code.  E.g. red = "this field does not exist for this entity"; orange = "this field exists but is a different field type", etc.

  This might come with a "use at your own risk" label, because you may get some pretty odd results.

  Now, a cross-entity query could also result in a multi-grid view.  So if I searched across all entities for the tag "chipmunk", the view could display a separate table for each entity with matches.  (In other words, I would not define which tables were part of the multi-grid.  The query results would drive that.)  The downside here is that I would be already be forced into "grouping" by entity type.  If I got my search results back in a single table, I could sort and group any way I wanted.

  Am I making sense?