For me the eye toggle makes sense, as an Adobe user I know immediately what it means. Your users may not use those products, and there may be copy write with Adobe to consider there. The toggle switch is functionally the same, as would be a square check box. So for me the toggle switch with a labelled column fits and would seem constant to the design.In respect of the question, you may have answered it yourself, and validation should be with the actual users.
An alternative approach (which is probably inferior) is to use the existing check box as a selection of the elements to want to hide. The context menu (or such like) has a hide command. How do you unhide ? Same process; as I understand it is only hidden to the presented portal users and only requires to be indicated as hidden in this interface. You could indicate visibility by "dimming" each hidden row, or using a small icon (like the eye I suppose)
On the 2nd bullet point, this is not related to the focus of row visibility to the portal users, but whether the user perceives the table as editable. This is an interesting question.
So the obvious answer is to let the users know that the data is editable. How ? Just tell them that. You can tell them in a few ways:
- New users have an introduction tutorial when they first use the software, perhaps just as a popover. The tutorial can be called back whenever, by selecting from help menu (or such like)
- Like (1) you have a popover which is dismissed easily with "tip of the day" and the tip about this being inline editable will have a high priority in early use
- Additionally your product is sold with training provision. Trained users will know that this is how it works
- Indicate visually that this is all editable. OK, so it is a difficult thing to be sure about in an interactive system.
Expanding on (4) consider that your App is like a spreadsheet, just more specialized to a specific purpose. I am no fan of spreadsheets, and only use it when I have to. However, there are two contexts about spreadsheets. If you fired up a spreadsheet app for the first time in your life, you would likely be presented with a blank grid of empty boxes. How would you know that these are editable? What happens is you have a blank "canvas" in front of you, a keyboard and a mouse. Inevitably you click screen and see what happens. The empty box is highlighted. Still puzzled you tap the keyboard, the letters or number appear on the screen. After a few minutes of playing, you get the basic function of the App. Although, to use it properly, you feel there must be more to it. You are going to go get the training, or read the manual if you are interested. However, you actually learned more by playing in 5 minutes. The manual is tedious, and methodical, but you do not have time to wade through the slow, and supposedly idiot proof tutorials. Instead, you really get proficient by having tasks and challenges in the software. Especially you learn when you see others using the program, and start to teach others likewise.
From a static image of the spreadsheet you would have no clue. you have to interact to see it working.
The other context is this. You start a new job and never used a computer before. You are shown the Apple Mac, and assured it is as easy as pie. Your boss wants you to make some edits to a company report in a Numbers spreadsheet. This report has formatted texts, graphics, and tables of calculations, also presented as bar and pie charts. Theres only one thing to do, you are going to have to find a friendly co-worker to help you get started, and hold your nerve! If you lied about having Apple Mac experience in the interview, you are sweating now
But these days, most people are not so phased by the sight of a computer or even a spreadsheet. What may be on the line may be their reputation as a good employee; they definitely don't want to screw up. There is an easy deflection: the UI is hopeless ! Quite often this is the case... it depends. If the company have invested in the solution they will want to make it work. However, a bad UX will eventually be a downfall, as frustrated users complain.
So really the issue is one of quality.
These two contexts of a spreadsheet apply here as well.
First test is the experience when the database is empty, and the (naive) user is left with the software, and left to their own device to play and explore the interface. Do they discover that it is editable just as the spreadsheet user did? If not, what is the spreadsheet doing that your UI is not?
Second test is the (savvy) user who has not used the system presented with a populated data scenario. Will they be able to get going with edits, or will they need help?
In the second scenario, it is no embarrassment if they need help. The spreadsheet user needed help in that context, if only to understand the domain of the data, and to be brought onboard.
