I'm starting a new site for a client. They have different user roles depending on what account you sign into on their site. Some users will see all options others won't. Some will see options that other accounts can't and vice versa. I was wondering if I will need a separate view-page made for each type of account or if I could use one view-page but lock specific people out from seeing specific things on their page. If able to do either way what would be the easier/recommended of the two.
I think you should use second variant, cuz support a few page very hard. So if you chose second variant you just use #if(isAdmin){one html} else {other html} in your view page.
I have created some utility code that allows me to take text entered into our content management system and dynamically compile and invoke it with a method similar to this.
But this raises a security risk--since a content author could mistakenly (or worse--maliciously) enter code that would do things outside of what I am looking for. Any recommendations for keeping this functionality open, but be able to prevent certain types of code from being written? For example, there are obvious things to limit like writing to the file system.
My initial thought is excluding certain assemblies, but I am curious if anyone has any clever ideas on this.
Don't do this. There are endless possibilities for what a user could write and you won't be able to prevent them all. In security you should always specify what a user can do instead of what he can't do (whitelist instead of blacklist) because you will miss something if you do it otherwise.
In this specific case, allowing a user to write arbitrary code never seems like a good idea. Instead, you should choose specific operations that a user can perform and add a button/control for each one.
If you REALLY need such functionality consider creating very limited functionality. Don't allow users to enter text; give them "blocks".
Start with very basic, limited set of instructions and add new ones only when asked to.
To streamline our content editors' experience, I want to ensure that the languages that show up in the publishing dialog window are limited to the languages to which the editor has Language Write access. We've set up Language Write for our various editor roles appropriately, but the entire selection of System > Languages still shows up in the publishing dialog (screenshot below -- the Publish Language section is what I'm looking to streamline based on lang write perms). I've tried denying Language Read for a non-essential language to see if that did it, but it did not. Is there a way to do this?
Wether the language is shown in the Publish dialog is not depended on the Language Read access right.
It's simply the Read right that determines this.
Have you broken inheritance on the languages? By default the everyone group has read access to the languages, so you need to specifically break inheritance for all other languages when selecting a English (Canada) role for example.
I've just tried this and removing Language Read on a particular role removes the language from the publish language list. Use the Access Viewer (>Security Tools) to make sure that Language Read is not inherited from another role.
Look at the method which builds the Publish dialog in dotPeek, this is the codebeside for sitecore/shell/Applications/Dialogs/Publish/Publish.xml
BuildLanguages() method in Sitecore.Shell.Applications.Dialogs.Publish.PublishForm class in Sitecore.Client.dll
Also, make sure that CheckSecurityOnLanguages in Sitecore config is set to true.
Be aware, if you are running multi-site and have different permissions on different branches, make sure that you have Publishing.CheckSecurity and Publishing.RequireTargetDeleteRightWhenCheckingSecurity otherwise users will be able to cross publish items, which is not what you want.
http://sitecorebasics.wordpress.com/2011/04/12/publishing-security-basics/
[EDIT] #Ruud, you shouldn't specifically deny Role access to an item, instead you should break inheritance, that way if you compound roles (i.e. a user belongs to multiple Roles) the user will still have access to that item. If you deny access, no other permission will be able to override it.
Sitecore Worst Practices Blog Series: Security
To prevent denial from overriding allowance, avoid denying access rights in favor of breaking inheritance and granting access rights.
Sorry, don't have enough rep to comment directly on your post.
I would like to check the load speed of each page in a particular asp.net website (based on C#). I thought of creating a class for timing the loading and execution of a certain element. I'd like to create a stopwatch object on each user control and on the page itself to get diagnostics on how long the page takes to load altogether. When debug is enabled, we could then see the load times of each of the pages, as well as each of the elements.
I don't want to save it in session, but I really can't think of a way around it.
I was thinking that a nice implementation would be to include a class that I write which will track the stopwatch values for each of the master page, page, and user controls as they load, but where could I save each execution time when it was done? I suppose I could use Session, but is this the only way to save data across user controls and pages?
What would be the best way to do this?
Besides using a logging framework you could use the tracing you need by using the ASP.nets out of the box tracing and diagnostic features [http://msdn.microsoft.com/en-us/library/bb386420.aspx] or you could use something like elmah for other needs. Try not to re-invent the wheel but make a car out of it that flies. Good luck!!
I would use a logging framework like log4net etc... Especially since you're only doing it for debug mode. You can define warning levels to match your loading speeds if something is slower than expected...
I would agree with other answers in that leveraging a logging implementation would be sufficient while doing related logic, such as writing to the log, on page Unload().
If this is an MVC site, you could check out the MVC Mini Profiler. It is available as a Nuget package.
In informal conversations with our customer service department, they have expressed dissatisfaction with our web-based CSA (customer service application). In a callcenter, calls per hour are critical, and lots of time is wasted mousing around, clicking buttons, selecting values in dropdown lists, etc. What the dirrector of customer service has wistfully asked for is a return to the good old days of keyboard-driven applications with very little visual detail, just what's necessary to present data to the CSR and process the call.
I can't help but be reminded of the greenscreen apps we all used to use (and the more seasoned among us used to make). Not only would such an application be more productive, but healthier for the reps to use, as they must be risking injury doing data entry through a web app all day.
I'd like to keep the convenience of browser-based deployment and preserve our existing investment in the Microsoft stack, but how can I deliver this keyboard-driven ultra-simple greenscreen concept to the web?
Good answers will link to libraries, other web applications with a similar style, best practices for organizing and prioritizing keyboard shortcut data (not how to add them, but how to store and maintain the shortcuts and automatically resolve conflicts, etc.
EDIT: accepted answers will not be mini-lectures on how to do UI on the web. I do not want any links, buttons or anything to click on whatsoever.
EDIT2: this application has 500 users, spread out in call centers around North America. I cannot retrain them all to use the TAB key
I make web based CSR apps. What your manager is forgetting is now the application is MUCH more complex. We are asking more from our reps than we did 15 years ago. We collect more information and record more data than before.
Instead of a "greenscreen" application, you should focus on making the web application behave better. For example,dont have a dropdown for year when it can be a input field. Make sure the taborder is correct and sane, you can even put little numbers next to each field grouping to indicate tab order. Assign different screens/tabs to F keys and denote them on the screen.
You should be able to use your web app without a mouse at all with no loss of productivity if done correctly.
Leverage the use of AJAX so a round trip to the server doesn't change the focus of their cursor.
On a CSR app, you often have several defaults. you should assign each default a button and allow the csr to push 1 button to get the default they want. this will reduce the amount of clicking and mousing around.
Also very important You need to sit with the CSR's and watch them for a while to get a feel for how they use the app. if you haven't done this, you are probably overlooking simple changes that will greatly enhance their productivity.
body { background: #000; color: #0F0; }
More seriously, it's entirely possible to bind keyboard shortcuts to actions in a web app.
You might consider teaching your users to just use the Tab key - that's how I fill out most web forms. Tab to a select list and type out the first few letters of the option I'm attempting to select. If the page doesn't do goofy things with structure and tabindexes, I can usually fill out most web forms with just the keyboard.
As I had to use some of those apps over time, will give my feedback as a user, FWIW, and maybe it helps you to help your users :-) Sorry it's a bit long but the topic is rather close to my heart - as I had myself to prototype the "improved" interface for such a system (which, according to our calculations, saves very nontrivial amounts of money and avoids the user dissatisfaction) and then lead the team that implemented it.
There is one common issue that I noticed with quite a few of CRMs: there is 20+ fields on the screen, of which typically one uses 4-5 for performing of 90% of operations. But one needs to click through the unnecessary fields anyway.
I might be wrong with this assumption, of course (as in my case there was a wide variety of users with different functions using the system). But do try to sit down with the users and see how they are using the application and see if you can optimize something UI-wise - or, if really it's a matter of not knowing how to use "TAB" (and they really need to use each and every of those 20 fields each time) - you will be able to coach a few of them and check whether this is something sufficient for them - and then roll out the training for the entire organization. Ensure you have the intuitive hotkey support, and that if a list contains 2000 items, the users do not have to scroll it manually to find the right one, but rather can use FF's feature to select the item by typing the start of its text.
You might learn a lot by looking at the usage patterns of the application and then optimizing the UI accordingly. If you have multiple organizational functions that use the system - then the "ideal UI" for each of them might be different, so the question of which to implement, and if, becomes a business decision.
There are also some other little details that matter for the users - sometimes what you'd thought would be the main input field for them in reality is not - and they have an empty textarea eating up half of the screen, while they have to enter the really important data into a small text field somewhere in the corner. Or that in their screen resolution they need the horizontal scrolling (or, scrolling at all).
Again, sitting down with the users and observing should reveal this.
One more issue: "Too fast developer hardware" phenomenon: A lot of the web developers tend to use large displays with high resolution, showing the output of a very powerful PCs. When the result is shown on the CSR's laptop screen at 1024x768 of a year-old laptop, the layout looks quite different from what was anticipated, as well as the rendering performance. Tune, tune, tune.
And, finally - if your organization is geographically disperse, always test with the longest-latency/smallest bandwidth link equivalent. These issues are not seen when doing the testing locally, but add a lot of annoyance when using the system over the WAN. In short - try to use the worst-case scenario when doing any testing/development of your application - then this will become annoying to you and you will optimize its use - so then the users that are in better situation will jump in joy over the apps performance.
If you are in for the "green screen app" - then maybe for the power users provide a single long text input field where they could type all the information in the CLI-type fashion and just hit "submit" or the ENTER key (though this design decision is not something to be taken lightly as it is a lot of work). But everyone needs to realize that "green-screen" applications have a rather steep learning curve - this is another factor to consider from the business point of view, along with the attrition rate, etc. Ask the boss how long does the typical agent stay at the same place and how would the productivity be affected if they needed a 3-month term to come to full speed. :) There's a balance that is not decided by the programmers alone, nor by the management alone, but requires a joint effort.
And finally a side note in case you have "power users": you might want to take a look at conkeror as a browser - though fairly slow in itself, it looks quite flexible in what it can offer from the keyboard-only control perspective.
I can't agree with the others more when they say the first priority of the redesign should be going and talking to / observing your users and see where they have problems. I think you would see far more ROI if you find out the most common tasks and the most common errors your users make and streamline those within the bounds of your existing UI. I realize this isn't an easy thing to do, but if you can pull it off you'll have much happier users (since you've solved their workflow issues) and much happier bosses (since you saved the company money by not having to re-train all the users on a completely new UI).
After reading everyone else's answers and comments, I wanted to address a few other things:
EDIT: accepted answers will not be mini-lectures on how to do UI on the web. I do not want any links, buttons or anything to click on whatsoever.
I don't mean to be argumentative, but this sounds like you've already made up your mind without having thought of the implications on the users. I can immediately see a couple pitfalls with this approach:
A greenscreen-esque UI may not be
more productive for your users. For
example, what's the average age of
your users? Most people 25 and
younger have had little to no
exposure to these types of UIs.
Suddenly imposing this sort of
interface on them could cause a
major backlash from your users. As an example, look at what happened
when Facebook decided to change its
UI to the "stream" concept - huge
outrage from the users!
The web wasn't really designed with this sort of interface in mind. What I mean is that people are not used to having command-line-like interfaces when they visit a website. They expect visual medium (images, buttons, links, etc.) in addition to text. Changing too drastically from this could confuse your users.
Programming this type of interface will be tough. As in my last point, the web doesn't play well with command-line-like or text-only interfaces. Things like function keys, keyboard shortcuts (like ctrl- and alt-) are all poorly and inconsistently supported which means you'll have to come up with your own ways of accessing standard things like help (since F1 will map to the web browser's help, not your app's).
EDIT2: this application has 500 users, spread out in call centers around North America. I cannot retrain them all to use the TAB key
I think this argument is really just a strawman. If you are introducing a wholly new UI, you're going to have to train your users on it. Really, it should be assumed that any change to your UI will require training in one form or another. Something simple like adding tab-navigation to the UI is actually comparatively small in the training department. If you did this it would be very easy to send out a "handy new feature in the UI" email, or even better, have some sort of "tip of the day" (that users can toggle off, of course) which tells them about cool timesaving features like tab navigation.
I can't speak for the other posters here, but I did want to say that I hope you don't think we're being too argumentative here as that's not our (well OK, my) intent. Rather the reaction comes from us hearing the idea for your UI and not being convinced that it is necessarily the best thing for your users. You are fully welcome to say I'm wrong and that this is what your users will benefit most from; but before you do, just remember that at the end of the day it's your users who matter most and if they don't buy in to your new UI, no one will.
It's really more of a keyboard-centric mentality when developing. I use the keyboard for as much as possible and the apps I build tend to show that (so I can quickly go through my use cases).
Something as simple as getting the tab order correct could be all your app needs (I guess I'm not sure if you can set this in ASP.NET...). A lot of controls will auto-complete for the rest.