 | Anatoliy Zachynskiy 5/3/2008 6:47:02 AM There are 45 tables in my application now. >
Users see only some tables depending their roles.
But administrator can see all tables and it is difficult to make search in 45 tables.
Thats why I offer to place (show) some table in a TABs.
May be at first to do this in "setup" mode, later - also "work" mode.
|
 | Matt Warner 5/6/2008 10:18:42 AM Hi Anatoliy,
I had a similar issue and similar number of tables. I think your idea is good, but I also found a decent work-around. I turned off all of the display of tables that I don't normally need for "working". When I need to add something to one of the hidden tables, I go to "Setup", click on the table I need, then hit "Back". The table is temporarily displayed as a tab until you click on a different table. Hope that helps if you didn't discover that already ...
|
 | david sultani 7/18/2008 4:24:39 AM When an application has too many tables all table tabs are displayed at the same time at the top of the application. Imagine how confusing this will be when you have 50 tables or more.
It would be much better if it was possible to group some tabs. For example the application might have divisons below that have sub divisions and below that related table tabs.
I think in a big application all tabs displayed at the same time as it is now is not ergonomic and I think it should be easy to implement the idea.
|
| Anatoliy Zachynskiy 7/18/2008 5:20:44 AM See my idea "TABs for a tables (in "setup" mode)"
|
 | Andrew Winters 7/18/2008 7:30:18 AM I agree and also was wondering about the possibility of hiding tables from view. (Or is this possible now?). I have a few linking tables that do not get direct entries or view themselves and the user has no need to see.
|
| david sultani 7/18/2008 7:54:05 AM Hello Anatoliy,
I have a very similar problem. As you know, I also posted this idea without looking your idea. I think this need can be implemented very quickly and is very usefull.
David
|
 | Kirill Bondar 7/18/2008 8:06:51 AM David, a while ago Matt posted a workaround here: #209#.
Andrew, in a Setup > Tables > Manage Access for Table Records you'll see Show Tab checkbox.
|
 | Rick Cogley 6/27/2010 8:01:15 AM We are coming from Dabble, which has a different organizational paradigm, and we are definitely hitting a limit in TeamDesk with the number of tables we have. While TeamDesk does indeed try to arrange my many tables in an equitable manner, I would like to see a more flexible UI for these tabs, for instance arrows at left and right sides of the tab area, which scroll the whole tab group horizontally, or, a "more" button at the bottom of the tab area, which you click to expand the area in an ajax-y manner.
_|tab, tab, tab, tab|_
< |tab, tab, tab, tab| >
|tab, tab, tab, tab|
When you have too many tabs, apparently the overall table sorting has no effect at all. You can sort all you want, but TeamDesk ignores it (when there are many tables) and will organize them by some pattern. The recommendation is to reduce the number of visible tables utilizing roles. However, in a db where users need a large number of tables, that might not be possible.
We are thinking of what we can do with the HTML areas in Dashboards, for instance, perhaps putting links to tables there... We hope to not have to resort to such kludges.
Regards,
Rick
|
 | gerardo garcia 12/28/2010 2:54:14 PM Would be nice to clic on a general tab and this would show the subtabs only hiding the general ones.
|
 | Slava Shinderov 12/28/2010 3:41:46 PM Merged with:
209 - TABs for a tables (in "setup" mode)
215 - Table Tabs
|
 | Liquid Rapid 1/4/2011 3:18:46 PM This would definitely help. I work on several applications with 9-11 rows of tabs. Just coloring the tabs on the setup side the way they're already colored on the user side would give my eyes a way to distinguish groups of tabs by color.
|
| Kirill Bondar 1/12/2011 8:43:06 AM Workspaces are now at Labs!
|
 | Rick Cogley 1/12/2011 8:52:59 AM Yes! Nice!
|
| gerardo garcia 1/12/2011 10:28:23 AM Great! Thanks!
|
| gerardo garcia 1/12/2011 10:40:20 AM Feedback:
I was viewing table X that is part of workspace X.
When switching to workspace Y, I could still see table X in workspace Y.
Once I clik in other table from workspace Y, table X dissapeared.
Suggestion would be that once you switch workspace, it would place you in the first table of the current workspace instead of leaving you on the last table of the past workspace. Thanks.
|
| Liquid Rapid 1/12/2011 1:51:07 PM Nice! I like gerardo's suggestion, too.
|
 | Ben Fatchen 1/12/2011 5:44:43 PM Excellent, will come in very handy thanks.
|
| Kirill Bondar 1/13/2011 8:51:22 AM FIX: TD now navigates to the first available table after changing the workspace
|
 | Grant Simmons 1/13/2011 1:46:53 PM This is great! Thanks!
|
| Liquid Rapid 1/13/2011 2:06:53 PM It would be useful to me if there were a "Show in menu" option the way there is on views. In some cases, I'd like to create dashboards and link to them directly, but not show them in the menu.
|
| Liquid Rapid 1/13/2011 2:08:38 PM Whoops - I meant to post that last comment on the Multiple Dashboards idea.
|
| gerardo garcia 1/13/2011 2:36:06 PM @Kirill Thanks, navigation to first available table looks excelent.
|
 | basenine 1/14/2011 2:34:06 AM Have set this up and love it - a great idea and well implemented.
Would it be hard to have the tabs centered to the page?
cheers
Brett
|
| Kirill Bondar 1/25/2011 3:30:06 PM @Brett: we have no immediate plans to change existing page layout
|
| Kirill Bondar 1/25/2011 3:31:02 PM By the way: what if keyword search will limit results to tables contained in currently selected workspace?
|
| Liquid Rapid 1/25/2011 4:10:48 PM >By the way: what if keyword search will limit results to tables contained in currently selected workspace?
YES. I've thought that a limited keyword search would be very useful. In some cases, for example, I'd like to do a keyword search on a single table. I think doing it by workspace is a great idea.
|
| Kirill Bondar 1/27/2011 2:42:11 AM @Nathan: now search is limited to a tables in a workspace
|
 | Philipp Matuschka (MMB) 1/27/2011 3:32:43 AM What would be useful as well is if sub tabs were also limited to those in the workspace. So for example I have a relationship Company has Properties. I have a Workspace called Accountant, which does not include the table Properties. Yet when the Accountant clicks on a particular Company, it is shown with its Properties. So while the clutter of tabs at the top is gone, there is still a clutter of data below.
|
| Kirill Bondar 1/27/2011 9:46:44 AM @Phillip
On the way back, if Properties are allowed and Companies are not, should we remove Company dropdown from Property? :)
At the moment Workspaces behavior is more or less consistent with Show Tab functionality - tab can be hidden for certain role, but the data is available anyway. And in case user navigates to table-specific page such as view or edit we add the tab to the bar to indicate "current" table.
If you want to disable access to the data, use roles and access rights. I think it would be enough to prevent access for the view used to display detail records to remove detail section.
|
| Philipp Matuschka (MMB) 1/27/2011 10:14:41 AM @Kirill
It's not about disabling access to the Data. It's about reducing clutter and in some cases improving speed, exactly as with Workspaces in the first place. So in answer to your first question above, No, don't remove the drop down.
I currently have 14 tables which appear below the Company table, most of them with good reason. I've raised a few suggestions in the past about how to reduce clutter below a record and as a result increase speed.
- move to subtabs rather than showing the results for all the tables
- If I set the view to show only say 5 records initially, then allow clicking to show all records
- allow OR in Match conditions
- the suggestion above
It would be great if some, or even better all, of these could be considered.
|
| Liquid Rapid 1/27/2011 10:36:33 AM >@Nathan: now search is limited to a tables in a workspace
That's great, Kirill. Thanks!
|
| Liquid Rapid 1/27/2011 10:47:06 AM I agree with the proposal of allowing more control over details views. I'm not sure workspaces is the best place to do it. Suppose I *do* want those details views shown, even when the tab is hidden in the workspace? I wouldn't want to lose the capability to just hide the tabs because of further-reaching implications of the workspace configuration. I think role-based visibility restrictions will work for most applications with a small number of users. It's not too difficult to set up a new role, then restrict the views based on the viewing user's role. The role-based visibility restrictions may not work for applications with larger numbers of users, where I would want to show the details view to some users in a role and not to other users in the same role. Formula-based control over the visibility of details views would be perfect for this situation. http://teamdesk.crmdesk.com/answer.aspx?aid=12706&back=ideaexchange.aspx |
| Kirill Bondar 1/27/2011 1:19:47 PM @Phillip: we are trying to find right solution for a right problem. * Workspaces are to cope with tab clutter. Its concept is simple, clear and works without changes and exclusions in both setup and user modes. So I guess we've done with that. * Limit number of records in a detail views will definitely shorten the page yet there is a little chance the user will see the info she needs in those first five. Next step is to click more - and the page be completely reloaded: master data + all details by 5 records in each with single view expanded. Yet there is no performance gain: in many cases there is a little difference between querying top 5 or top 200 and in a "limited records" case the user will likely reload page twice. * "OR" is a peformance killer. In many cases it is much faster to query details by "condition1" then make another by "condition2" than querying by "condition1 OR condition2", ***especially in match conditions*** so it should be used with caution. We do not plan to expose performance specific functionality like query plans, optimization hints, indexes etc, so unlikey this idea will be implemented in a "write whatever condition you want" style. * What is left? "Sub-tabs." This one looks like an ideal solution - only active tab is loaded, others stay inactive until queried. And by the way it has pretty good score - vote here: Ability to control how to display related lists on record view screen |
| Philipp Matuschka (MMB) 1/27/2011 1:39:42 PM @Kirill
In order of your replies above
1. I'm going to have to take your word for it
2. I have to say that since I moved from IE to Google, this isn't an issue any more. On IE it could take 20 to 30 seconds to load a big page, on Google it is an acceptable 2-3 seconds.
3. Having multiple lists is exactly the problem. See also #114 and #371.
4. I've promoted that now, but note that it has been around since 2006.
|
| Liquid Rapid 1/27/2011 1:57:56 PM I agree with Kirill that workspaces have solved the problem they were intended to solve, and they've done that very well. Nicely done, guys.
|
| Kirill Bondar 1/27/2011 4:15:25 PM @Philipp:
My 2 and 3 concerns were about database performance.
We have vast variety of applications ranging from very simple to very complex. In some cases you can safely query thousands of records in seconds, in some cases querying five records can result a timeout. In latter case, we are trying to investigate the cause - sometimes creating indexes on a physical database level can improve the performance but in lot of cases it would be enough to simplify some formulas or restructure the data. Why? Not all operations are identical in performance. Not all operations perform at the same speed in different scenarios. Sometimes people find suboptimal way to do something - it is very easy to fall into the pit with formulas. Since it does the job anyway, they use the solution they found in every possible and impossible case. The app works slower and slower and starts displaying timeout messages after all. So: the less queries you make the faster your application is; and avoid using performance killers at all costs.
I'm not against "OR" in match conditions but it's a performance killer and it can be easily misused. Perhaps there should be a different way to get the same result.
---
As a side note IEs up to 8 are indeed slow when rendering large tables. Now I'm using IE9beta for a while - it's stable, solid, and rendering speed is decent.
|
| Liquid Rapid 1/27/2011 4:15:31 PM A little something I just noticed about Workspaces: If I'm in table X, then I switch to workspace Y which does not include table X, then I hit the back button in my browser - I'm returned to table X, but I'm still in workspace Y.
|
| Kirill Bondar 1/27/2011 4:25:18 PM Current workspace selection is stored in cookies. When you press back button the browser takes the page from the cache in a state you left it. But cookies are not reverted and the cookie still points to Y. I don't think this can be solved...
|
| Liquid Rapid 1/27/2011 4:32:05 PM Ah, yeah. I see what you mean. It's probably not a problem.
|
| Liquid Rapid 1/27/2011 4:36:39 PM It would be useful to me if I could restrict access to workspaces by role. I'd like to be able to create some development-only workspaces that users don't see. They would all include some of the common tabs, so if I just created the workspaces then they would all display to users.
|
| gerardo garcia 1/27/2011 6:15:42 PM from:
Kirill Bondar Staff 1/27/2011 2:42:11 AM
@Nathan: now search is limited to a tables in a workspace
@Kirill
This is great thanks.
Feedback: In one of the searches I did, I got a results for file attachments from tables not belonging to the workspace.
|
| Slava Shinderov 1/28/2011 5:08:02 PM > In one of the searches I did, I got a results for file attachments from tables not belonging to the workspace.
@Gerardo thank you for the feedback. Fixed.
|
