I have created two CKEditor plugins. Each of them uses an "Iframe Dialog Field", meaning that a dialog box is launched and the contents of that dialog box is a webpage (you can think of the entire dialog box as being like one big iframe).
Each plugin works perfectly on its own. However if I use both plugins in the same CKEditor app, they both end up displaying the same page, rather than two different pages, despite the fact that they point to two different pages. I see no reason why this should be happening. Does anyone know how to prevent this?
To make sure there is no confusion, an "IFrame Dialog Field" is a dialog box whose contents are another webpage.
Documenentation - http://ckeditor.com/addon/iframedialog
[ This is different from using an "IFrame dialog", which I believe is a plugin that lets the user add an iframe to the page.
Documentation - IFrame Dialog: http://ckeditor.com/addon/iframe ]
In terms of usage, when using an IFrame Dialog Field, you specify the url of the page to load in the addIframe() command. Here is an example of using a CKEditor Iframe dialog
https://gist.github.com/garryyao/1170303
Back to my issue - if I use just one of the plugins in my CKEditor, it works perfectly. Each plugin points at a different url, and opens that url as the contents of the dialog box. But, if I use both plugins in my CKEditor, although I see a different icon for each, both end up launching a dialog box which points to the same url. Depending which one I launch first, that is the url both end up opening. It is as if you are only allowed to use one IFrame Dialog Field in CKEditor, and the first one used overwrites all others.
This same question was asked a couple of years ago, with no response on the CKEditor forum. The person who asked the question posted his solution, or rather his workaround, which was to NOT use the IFrame Dialog Field altogether, but to instead use a regular dialog and then put an iframe element within it.
http://ckeditor.com/forums/CKEditor-3.x/multiple-iframedialog-plugins-display-same-dialog
That seems like an OK workaround, but it is a workaround and not a solution. I haven't tried it yet, and don't know what potential issues I will run into if I go down that route. I'd prefer to fix my existing code rather than rewrite the plugins, unless I have no choice.
Any help would be appreciated.
Since I have not found any further information, or received any answers here, I ended up going with the workaround mentioned at the end of my question - I used a regular dialogue box and put a big Iframe within it. This problem doesn't exist with that approach, and It looks pretty much the same as an Iframe dialog box. (Considering the almost total lack of community support with CKEditor customization, I've realized it is better to just adjust your design/concept to do what is more easily accomplished with CKEditor, rather than get CKeditor to do exactly what you want).
So I know this might sound crazy, as it is technically a security concern which I understand. So I'm just trying to find out if there's any ideas on how to handle something like this.
Anyways, long story short, I was told to look into figuring out a possible way to scrape information from another browser window/tab. I have been asked to do this because, and I know this sounds crazy too, but the users of our website are incompetent enough to not be able to copy/paste and or type correctly something from a different website. I know it's tough for some to have to have several things in their workflow, but this is basically what they do: Go to their first website (after logging in) and bring up a record with information on it...including an identification number. Then, the user should take that number and go to the second website, our website (after logging in), and type it that number in a textbox (and eventually do some other stuff). But we have found that getting that identification number from the first website to ours is difficult for them. Some copy/paste correctly, some copy/paste too much text from the page, some write it down on paper then type it in our website, and some just seem to have trouble visually "copying" the number from site to site.
What I was thinking was that this could happen: the user would have already brought up the record on the first site, then they would come to ours. They could click a button, and that would run whatever I/we here come up with, that goes and finds the other browser window, finds the specific text needed, and puts it in our textbox. Sounds simple, right? HA.
The first website is not owned or managed by us in any way, otherwise this might be a little easier.
A little bit of background information: unfortunately, I'm technically targeting IE >= 10 through 9, so if there's a solution just for this (why I tagged vbscript), then that's great. If there's a broader solution (like with an applet or browser extensions... http://crossrider.com/ ), then that's even better, but not important. If it helps, we already have a hidden applet on the page that accesses the OS (yes, it has the mayscript attribute on the element so it is able to), so I thought that could be something to incorporate with. Also, the way I expect to know which window/tab to access is by URL and/or document title - either will be very specific.
We cannot install stuff on the users' computers, at least something outside of the browser (like extensions). I'm not sure how browser extensions work, so I'm wondering if they'd need to be "installed".
I know of HTML5's postMessage, but it only has partial support in IE (and none in IE <= 7)...and the partial support refers to not including exactly what I might need. It also requires that the other website be listening (which we don't have control over, but technically might be possible to include). So it doesn't count :)
The things I found with Java are to possibly find the list of processes currently running, but I don't know how to access/control one. Especially how to access the browser's Document.
And vbscript...I just don't know. I don't know if it's just me, but I can't seem to find good documentation on it, so I'm not sure what can be done with it.
Even if I could get control of the other browser window, I don't know how I would get information from it (like the DOM).
I'm not looking for code, just ideas...I'll do the research. And although it may sound impossible, don't just brush it off because Javascript can't do it - I haven't.
UPDATE:
I ended up developing a browser extension with http://www.crossrider.com/ which wasn't ideal, but works.
You could use a bookmarklet for this ... the user would have to drag the bookmarklet into their bookmarks bar on their browser, but if doing that wasn't beyond your user's abilities/the technical restrictions you've mentioned, then you'd definitely be able to send the information you need back to your site that way.
You'd just need to give your users instructions to:
i) drag the bookmarklet into their bookmarks bar on their browser
ii) go to the website in question and click the bookmarklet
you could code the bookmarklet so that it would grab the info you need, and redirect the browser to your website. All done in one click.
I think you may be thinking about it in the wrong way when you talk about posting from one 'window' to another. You could write the bookmarklet so that it would do a http post of whatever information you wanted into your site from the other site, and it could also redirect the window that they were looking at when they clicked it (the other site) to your site. Or if, for some reason, you didn't want to redirect the the window that they had the 'other' site in to your site, then you could add a listener to your site so that once the bookmarklet had posted the info you require then the window with your displaying could automatically update. The first option would make more sense and be easier though.
Maybe to open the other site from button/link resided in your site using window.open() method?
I am using the asp.net Repeater control. (My company is heavily invested in that, so I can't change it.)
I need a way to create a poup edit window, specific to the row the user clicked on in the repeater, so the user can edit the data in that record.
We have the Telerik controls to use, but I don't know which one. I saw the radwindow, but can find no examples of using it in a repeater. Frankly, Telerik documentation is confusing.
I prefer to use client-side code, ajax and web-services. I'd like to prevent post-backs.
1) Please give me a reference to a specific example of using the Telerik radwindow inside a repeater for this purpose.
OR
2) Clue me in to a better idea.
Thank you.
I don't think there are explicit examples with an asp Repeater, but I found this one with a GridView. The approach should be the same, as it is just another databound control - it shows an easy way to open a RadWindow on the client by passing some parameters (it is actually not possible to open it on the server, it is a client-side object).
Some more complex examples I found on their site here and here. They both update a grid, yet they show a nice way to use AJAX to prevent a full postback.
I have a GWT app that when launched it takes you to a page with just a menu. So as a shortcut type thing I would like the users to be able to go straight to the page they want. So if the default start page is x, the should be able to say x/add and it will take them to the add page. How would I get that in gwt? Do I need a bunch of different entry points?
To accomplish this, you should use the URL's "fragment", which is the part after the #. For example, if your app is at /x, you could have a different UI displayed when someone navigates to /x#add
If you don't want to write this logic yourself, you should look into the gwt-presenter project, which was written to make MVP apps easier, but also includes an EventBus (to publish events to all corners of your app), and a PlaceManager to facilitate events being fired when the fragment changes (and to change the fragment at will).
Seems like a discussion we already had so I'll just link to the related question. Please see the answers and comments there. Basically, it might be advantageous to just interact with the History class directly, instead of introducing MVP to your project, but YMMV (I'm a huge fan of MVP myself, but it's not for everyone. Besides, I like to know the stuff "under the hood" ;))
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
In some application with UI, what is better (easy, friendly, etc.) to a user:
UI is static (don't depends on user state). E.g user see some button, but it's grayed out or when it's clicked, a message, that this action is not applicable right now, is shown.
or
UI is dynamic (depend on user state). E.g. user don't see buttons, that are not applicable right now. But after some action, buttons may appear/disappear.
Sorry for my French:)
In my opinion, a static GUI with disabled controls is preferable.
When some options are not visible, the user will not know they exist.
Both of those styles have their uses. Remember that you should always use the right tool for the job and that there are (almost) no absolutes in creating software.
A static UI with grayed out elements is preferable in most cases. By providing a simple non-obtrusive message (don't show a modal message box for instance) when the user clicks or tries to interact with the grayed out elements, you can train your users.
What really happens in most cases is that there is a grayed out menu and your users are left wondering what they need to fix to be able to click on that element. This is bad UI design.
A dynamic UI is also relevant if you have an extensive administration section that the logged in user should NEVER be able to use. By hiding the administration section, you avoid confusion and interface "overload" for users who will NEVER interact with the hidden interface elements.
A dynamic UI is required in applications like Adobe Photoshop. There are literally thousands of commands and menu items possible in Adobe Photoshop. The only way that any user could comprehend the interface is by hiding and showing user interface elements depending on the state of the application.
I always recommended a UI that is as unchanging as possible:
Don't surprise users
I don't think there is a right or wrong answer to this question, I think it is just a matter of opinion/preference.
Personally, I would expose all functionality to the user and just grey it out when it is not accessible. However, there are some situations where I would consider removing the buttons from view e.g.
Administrative options (probably don't want to expose this to users with lower priveledges)
RunOnce functionality (activating product/registering)
Reasons for this is there is no point in exposing functionality when the user is not meant to access them or if the functionality is just going to sit there greyed out forever...
Hope that helps.
If an action is not available
because the profile of the user
forbids its use do not show it at
all
If an action is not available only
because another action must first be
completed either :
Grey it out or
Leave it activated but on execution display a
message with a clear explanation of
why it cannot be executed
Make the action unavailable (by hiding, disabling, or using an error message) only if the action is logically impossible for the current state of the task, or to encode organizational rules on the actions certain users are permitted to do (e.g., privileges/permissions). Whenever possible make the user actions always available:
Use status indicators to discourage unnecessary actions, but allow them anyway.
Use verification and undo to prevent permanent damage from unadvisable actions, rather than disallowing the actions. Users may need to do something some day that is usually “unadvisable.”
Alter app design to make actions always possible in some way. For example, if a field needs to be filled out before an action can be done, prompt the user for the field, rather than disallowing the action.
Control user behavior through organizational policy, not software. Policies are easier to change when the business rules change or when there’s an exception or emergency.
Use disabling when:
The user can do something in the app to make the action available.
Availability is achieved through controls in the same window or its parent.
The user can easily figure out which control does this.
Use toggling controls rather than disabling for turning processes on and off.
Use read-only text boxes rather than disabled text boxes for data that is applicable for the current state unchangeable by the user.
Use hiding (“dynamic UI”):
For actions that are never available to the user in his or her current job.
For indicating different virtual places or things (e.g,. pages on a tab control, where each “tab” is a different place or thing). Make sure visual design is compatible with this: if you are representing different places, then make it look like different places (e.g., the way tabs do)
For swapping large numbers of controls with alternative controls.
Use layout, symbols, and text to explain unavailability, especially disabling. For example, mark your required fields; use tooltips to say why a button is disabled.
Use error messages rather than disabling or hiding when there no other means to indicate graphically or textually how to make an action available.
Further details and rationale at http://www.zuschlogin.com/?p=40.
I nearly always keep the UI static and simply disable (grey out) components that aren't applicable at this moment in time. It can be jarring to the user and confusing if components move around as you show/hiden them as the state changes.
I have seen good examples of both, and bad examples of both.
Your primary goal should be in making sure that your UI design (whatever route you choose) makes the entire process logically sensible to your intended audience.
dynamic is better if you don't want to frustrate your users
Well, that's the idea behind the latest MS Office, right? Controls that are around based on context. That, versus older versions with lots of grayed-out menus and toolbar buttons.
I worked for a number of years on control systems and in those environments, we mimicked the hardware controls (toggles, dials, buttons) that were, of course, static though not always usable. This was a customer requirement and their position was that the operator using the system expected button X to always in the same place. But from the designer and developer standpoint, I was frustrated by the cluttered UI and didn't like it when 95% of the buttons on a screen were grayed out.
I think that it will depend on your audience and the domain and customer requirements. In my shop, I make things dynamic and offer controls that make sense based on context. Typically, we don't show grayed out buttons or menu options that aren't available in the current context. Once the users recognize that they follow certain workflows and those involve particular UI elements when appropriate, they have no problems with (and probably prefer) a dynamic UI.
Less is better.
Why not do both and let the A/B testing tell you what your users prefer?
I think it's better to focus on the user productivity and on the business the software is implementing.
To show operations that does not make sense for a specific user or in a specific moment will not help, disabled or not.
For example, if you have a software that is used in several departments of an organization, each user/department will only be interested in the part of the software that implements the part of the business he is involved to. Anything else is useless for him and only will make the software experience worst. The same applies for a screen that is usefull for a user but shows useless options.
I'd suggest prototyping both and asking your users (or a representative sample) which they prefer and why.
Just to re-iterate what Mitch Wheat said really.
If you make buttons disappear and reappear depending on user actions then there is the danger that the user might think that they've done something that's broken the application.
You are also hiding actions from the user, so it will be harder for them to discover what it can do.
Disabling buttons is a well known paradigm and users will be able to see everything that your application can do and will experiment to see how to enable them.
I think it depends on what users you want to hide design for but in general I would opt for the static version. Don't forget that a user interface doesn't only provide functionality but also information. If you grey out a button you inform the user about it's state (by what he can do and what not) more clearly than removing buttons.
The remove button aproach can work for users that in general have good understanding of the system like admins. But I think you should use this with causion
Grayed out buttons are better, because then the user will know that under some situation such a function is available (and depending on the context the user might be able to guess when it is enabled), and the visual cue of being grayed out will signal to the user that the button can not be clicked, so the user will not try to click it (the problem with a message after clicking is that it comes too late - the user already made a mistake).
Whatever you choose, use constant positions of the buttons. Users often are not read text on the buttons.
Depends. But a clear and compact GUI is a nice thing to have. Why bother with 10 fields/controls you cannot change or use at all. For example on stackoverflow you have a reduced UI if you only have a low reputation, because it doesn't matter at all to the user, that one day he might be able to use them. Another thing is that controls (with borders) usual take more space than just text. If you have information, that currently cannot be changed, I would present them in a very compact text field/label. Depending on the information it even could be placed outside or far way from the form.
According to Joel - neither :-)
Both can make sense, as long as you use paradigms the users are familiar with.
The tab control is basically a dynamic UI that changes depending on the state.
Consistency is probably the most important thing when designing an UI. If buttons pop in and out, they are seen as a visual stimulus, and the user will "spend" attention looking at them.
A subtle, but clearly disabled button (not disappearing) is my preffered choice for designing UI....
.. So I guess that's option 1 :)
A combination of the two.
If a function is not applicable in the current state, disable the button but also place an icon next to the button and associate a tooltip with the icon. The tooltip should explain why the user can't use the button right now.
Attaching the tooltip directly to the button doesn't work so well. Most users won't even hover over the button as they won't expect it to do anything.
And avoid exclamation mark icons. They suggest the user has entered an invalid value (unless they actually have.)
I'd like to say I always do this, but unfortunately it does take significantly more coding time, and clients aren't always willing to pay for that.
A modal UI introduces mode errors. Always.
You currently seem to want to choose between two different ways of presenting a modal UI. From those I'd say the first one is superior (unless you really have many possible commands, see the Office 2007 UI for a good example how to handle this, but it's not common to have that many).
If you have the space and you haven't too many controls then I'd really go with disabled controls as it shows th user what is possible. Furthermore you might want to make it really clear which mode the UI is in (not just from the buttons that are enabled). I've seen user interfaces where you had disabled buttons but the user couldn't figure out what he has to do to enable them.
In any event be sure to do usability testing to find out what way is less error-prone on behalf of your users.
I like to keep all advanced options hidden under a "More >>"/"Less <<" button, or "Advanced Mode" checkbox, depending on the context and application.
Once clicked/checked, the window expands to reveal more options.
In terms of action availability though (like a Wizard featuring Next/Previous buttons) I always show them, and enable/disable them according to what functionality is possible.
The dynamic UI is done like the UI may keep changing. The fields may keep changing. So depending upon that the information of the field fetched from internet the ui is designed.
Rembr! all the similar fields have same design so u can keep changing the UI design and hence the application. without uploading the newer version of the application to the cloud or play store you can change the design of the UI.
As a example the UI pattern and fields are filled in the excel sheet and uploaded to cloud and the app has the access to download the excel sheet.
the above explanation holds good for an android dynamic app development