Query re CSH linkage style
I am currently building the Context Sensitive Help text. (see http://www.openvpms.org/documentation/csh ).
As regards link handling (eg that to 'using wildcards' in the page http://www.openvpms.org/documentation/csh/1.7/patient/select ):
a) should this sort of link (where one is providing extra information) be one that opens in the same page, a new page, or what?
b) should the link URL be
- as relative as possible (eg ../../concepts/wildcards ) or
- less relative (eg /documentation/csh/1.7/concepts/wildcards) or
- hardcoded (eg http://www.openvpms.org/documentation/csh/1.7/concepts/wildcards )
I am am currently using 2, but I suspect that 1 might be better. 3 is wrong because it makes it more difficult to port things in the future.
Any advice?
Regards, Tim G
Re: Query re CSH linkage style
a) I don't really think it matters. Half of people would say one thing the others would say the other. You either need to get back to the page by closing a tab or window or using the back button.
Personally, I prefer the same page. I can choose to open things in a new tab if a want to but don't like being forced to open a new tab.
b) I think that option 2 is fine.
Re: Query re CSH linkage style
Thanks Matt - I will go with your suggestions - they are also the easiest to use.
Regards, Tim G
Re: Query re CSH linkage style
One issue with not using relative links is that when it comes time to duplicate the existing book into a new tree for the next release, all of the links will point to the previous version.
I don't know if Drupal provides a module to migrate links, but it would be a PITA to do them all by hand.
-Tim
Re: Query re CSH linkage style
Tim A - you are absolutely correct. For the sake of migration I do need to use the 'as relative as possible' option - or slightly less relative - BUT we MUST stay below the 1.7 level - that is no link should include the 1.7 folder. Tomorrow morning I will start correcting the stuff I have created to date.
Regards, Tim G
Re: Query re CSH linkage style
Ok first comment
Most if not all help systems in windows open a new window above the existing window. The window shouldn't be maximized it should be set at say 50% screen width and 75% height, the user can then adjust (we could set this in the PROPS file
Currently the system opens a new window set at whatever size the user has open ...for OPENVPMS users that is going to be maximized so in essence that opens a screen over the top of what users are trying to understand with the help screen....forcing them to minimize and resize...more clicks more user frustration (who are probably already frustrated because they are using help)
My 2 cents...open the help in a new window (not a new tab) with a approximate size as described above set it to the lower right of the screen real estate.
Currently:
In firefox it seems to open a new maximised window
In GoogleChrome it opens a window similar to what I described BUT GOOGLE CHROME forces a change the google chrome help screen (https://support.google.com/chrome/?p=help&ctx=keyboard) further confusing users. The Chrome help opens in a new browser tab, meaning due to google loading faster that the www.openvpms site, they never see the new window for CSH
IN Ie10 it opens in a new window appropriatly sized, BUT also opens a 2nd window cascaded on top to http://windows.microsoft.com/en-AU/internet-explorer/internet-explorer-h...
If we are going to hijack f1 as a help button in open, this sort of browser help is going to need disabling....its going to confuse users who are trying to understand OPEN
Ben
Re: Query re CSH linkage style - popups & chrome
I have just fired up 1.7 alpha on a server in the practice in Hong Kong. [Until now I had been doing all the CSH development on my laptop's local OPV system and on the alpha 1.7 demo system.]
Two rude shocks:
1) When I access the office system from Firefox on my laptop, it treats the F1 invoked calls to the CSH URLs (eg http://www.openvpms.org/documentation/csh/1.7/concepts/tills ) as popups. It also treats the links on the Help window as popups (except for the 'subscribe' one down the bottom).
[Chrome also treats them as popups] Is there anything we can do about this?
(Looking at the html, the links on the help window are not html hrefs but are made to look like links by underlining - so I suspect that a popup is detected when there is a jump to a url that didn't come from an href.)
2) Chrome is the browser of choice at the office, so this was the first time I have played with chrome and the CSH links. I agree with Ben - it's a pig. Firstly there is the funny F1 behaviour that calls up the Chrome help, but it also opens the CSH page - BUT not nicely like Firefox in a new tab, but in a new window. I did find a partial solution - the 'One Window' addon for Chrome at https://chrome.google.com/webstore/detail/one-window/papnlnnbddhckngcblfljaelgceffobn
[you need to open this URL in Chrome]
I must admit that I very strongly sympathise with Ben's suggestion that we move away from F1, and adopt Tim A's ? solution. [I can see how this works with a window - and I assume that on the main screen there is a ? next to the Help entry on the top top.]
I have not played with tablets but I suspect that you want a button mechanism for these. For people with keyboards, should we consider 're-purposing' Alt-H. It is currently uses as a shortcut to the Help entry on the top line. What would be the effect if we switched from F1=Help to Alt-H = help and leave people to click on Help on the top line.
I have just has a quick play with IE10 (running in IE10:standards mode) and it has the same F1->microsoft help problem, and also the 'its a popup' problem.
Arrrggghhh!!!
Regards, Tim G
Re: Query re CSH linkage style
Ctrl-F1 works in Firefox, Chrome and Safari (at least on Windows).
IE intercepts it and displays its own help as well, but we've never supported IE in terms of keyboard shortcuts, so I'm not too concerned.
Here's a mockup of a help icon on popup windows.
It would look better closer to the close icon, but there is a danger of clicking it accidentally.
Not sure where to put it on the main window.
An alternative would be to put a help button on the bottom.
This might be a problem on low resolution displays for popups where there are a lot of buttons already, e.g. the Visit editor.
Re: Query re CSH linkage style
Tim - I think that the ? is quite elegant. On the main screen I would put it a little to the left of the message envelope icon.
Help button - if you go this way, then we would need to change the Help entry in the top menu line. I think the ? approach is better. [But I am not a tablet person.]
The use of Ctrl-F1 in place of F1 allows a more uniform approach.
[Arrrrgh - I have just realised that I have some 200 screen shots to revise !!!!]
Regards, Tim G
Re: Query re CSH linkage style
Ctrl F1 does nothing on my version of FF and 1.7a, why wouldnt we use ALT-F1 to be consistent with the current shortcut system implemented already. even better why not make CSH help open with alt-h and the regular help box open with alt-shift-h ie alt-H
Ben
Re: Query re CSH linkage style
Ben:
a) Ctrl-F1 - agreed it currently does nothing - I think Tim A was putting it up as a proposed conmmon solution.
b) I agree - Alt-h for all Help and something else (or no shortcut) for the Help on the top menu. (Note that explaining that Alt-h is different to Alt-shift-h and that althouth the H in Help is underlined you need to use Alt-shift-h to get at it, but the for Suppliers etc you can just use Alt-s - all sounds a nightmare.)
[and has the MAJOR advantage to me that I don't have to adjust 200 screen shots - but probably only 50 to remove the underline from the Help button.]
Ben - since you suggested it, I assume that there is a way of doing Alt-h on an iPad. [Googling 'ipad alt keys' indicates that there is a problem.]
Regards, Tim G
Re: Query re CSH linkage style
I tried using open on ipads...i found it doesnt have enough screen realestate, we are about to upgrade all our monitors to 21" plus to give more realestate while maintaining font sizes.
One of my vets cant read 10pt font on a 17" 1280 x 960 screen, so he sets his res to 800x600, which seriously cuts into screen realestate for some of the popup windows open uses. I had to change all the stylesheets for that res to make it work, but it still cuts off invoice totals etc.
So back on topic....I have no clue regarding alt keys and ipads, Matt can probably answer that.
Re: Query re CSH linkage style
This is a bit confusing as there are 2 very similar threads on this. Anyway, the issue with ipad or any other touchscreen device is that keyboard shortcuts are useless as there is no keyboard unless you are entering information into an input box on the screen.
I like the ? button option but I don't think the big gap between this and the close (X) button is necessary.
Just to add a bit more confusion to the whole issue the function keys on macs are disabled as function keys by default and have special functions such as volume control, etc. Therefore any keyboard combination using function keys won't work for macs.
Matt Y.
Re: Query re CSH linkage style
My first preference would be to put a Help button on the button row, although this causes issues at 800x600 in the Visit editor. At this resolution, the existing buttons fill the available space.
My second preference would be to put a [?] button on the title bar, replacing the [x] button.
My third preference would be to put a [?] button on the title bar, to the left of the [x] button.
-Tim A