Domino on mac client - weird doc behavior - macos

I support an old (late 90s) Domino DB that has a growing number of Mac users. In some docs, layout regions become grayed out once you click anywhere in the doc even though it's still editable, i.e. if the cursor was in a text field and you type something blindly and save it, it will be there when you reopen the doc. It doesn't happen in all docs and I have found no pattern.
Any Domino designers seen any behavior like this? I don't this there is anything too weird in the code; onBlur or onChange used in some cases - that sort of thing. Nothing too complicated really. Thanks!

Layout regions are a nightmare to maintain: there can be objects with differing hide-when formulas stacked on top of each other that might be causing this. I suggest making a copy you can work in without worry: inspect each object fully (keeping notes) then delete. Keep drilling down until you hopefully hit an object that matches your grey-out. If you don't find one, then it could be a bug as posted by Richard Schwartz. As Richard and D.Bugger suggest, perhaps it's time to rebuild the functionality without using a layout region: layout regions never worked with a web browser.

Related

Multiple synchronized CKEditor instances on the same page?

I'm working on a document-editing application using CKEditor, where the user can open multiple documents side-by-side in a pair of editor instances.
Most of the time, the user will be editing two different documents, but it's also possible that the two editor instances might contain different views of the same document. That makes things tricky, since I'd like to changes in one editor instance to be immediately reflected in the other instance.
Without hacking the CKEditor core, is something like that possible?
If not, would it be possible to write a plugin that would provide that kind of functionality?
What about if I was willing to get into the core code and hack around a bit? How difficult would it be?
This is a very similar case to a collaborative editing like Google Docs allows. The only differences are that you won't need to synchronize this via network and that it's very unlikely (if not impossible) that the same documents will be modified by two users at the same time. This makes things simpler... a little bit.
A year ago me and my colleague (we are both CKEditor core devs) took part in Node.JS Knockout and our plan was to create a collaborative editor based on CKEditor. It was only 48h, so the result is not impressive, but it worked. The source code is here.
The main problem you'll have is applying changes from editor A to editor B without breaking a caret position in editor B. Basically, you cannot just take data from editor A and set them in editor B, because everything in editor B will be reset including scroll position and caret. Unless this is not a problem, but I assume it is.
So you would need to:
either find a nice algorithm for extracting changes (like diff, but working on a DOM tree, not an HTML string) made in editor A and an algorithm to apply them to editor B (and this is what we implemented on Node.JS Knockout),
or find a way to guess caret position after resetting data in editor B; for example you can remember the caret context in editor B before setting data and try to find it in data that will be loaded.
Both ways are doable, but the first way will give better results if you'll implement it well. However, if your you don't know enough about DOM and contenteditable, then this task may overwhelm you. In this case I would advise to block possibility of opening one document twice.

Page items sliding in in metro style apps

I'm experimenting with creating a metro style app with Visual Studio 2012, I am not the most experienced designer but one thing with my applications is confusing me.
I have been working with 'basic pages' instead of blank ones for the different pages in my application for design consistency, however it seems that these 'basic pages' have a strange behaviour. Every item I place on the page (buttons, text boxes, etc) will all slide in one by one when the page opens. For example if I run the application and navigate to a page with 10 buttons, it will do a brief animation where each button will slide in from the right side to the left side. When dealing with a large number of items on one page this can take a lot of time as each item slides in seperatley.
Looking at the properties for each item I have been able to change the direction it slides in while loading the page by changing the flow direction. Also with a bit of research I am thinking it could potentially be due to either the metro style 'enterPage' or 'enterContent' animations, though I can not be certain.
I have tried to experiment and figure this out, and search to find out what causes this so I can modify it (Ideally I would like to just group items together to slide in with each other) however it's kind of a difficult thing to search with vague words, so I'm asking here.
What is causing this and how might I go about modifying it?
EnterPage shouldn't be sequencing the animations. They do offset some of the animations of a number of elements, but it shouldn't be each one sequentially.
Are you using WinJS navigation?
Well after a bit of experimentation I figured out that putting all my page content inside a grid made them all come in at once like I wanted. I probably should have tried that earlier but everything was already inside an outer grid for the page, so I thought that woulda handled it.
I don't quite understand it fully, but that works for now.

Readymade Cocoa Spotlight UI Components

I'm new to developing on the Mac and am looking to implement an interface similar to Spotlight's - the main part which seems to be an expanding table/grid view.
I was wondering if there is a component Apple provides for creating something like this or is available open source else where.
Of course if not I'll just try and work something out myself but it's always worth checking!
Thanks for your help in advance.
New Answer (December, 2015)
These days I'd go with a vertical stack view ( NSStackView ).
You can use its hiding priorities to guarantee the number of results you show will fit (it'll hide those it can't). Note, it doesn't reuse views like a table view reuses cell views, so it's only appropriate for a limited number of "results" in your case, especially since it doesn't make sense to add a bunch of subviews that'll never appear. I'd go so far as to say outright you shouldn't use it for lists of things you intend to scroll (in this case, go with a table view).
The priority setting can be used to make sure your assumption of what should be "enough" results doesn't cause ugly layout issues by letting the stack view "sacrifice" the last few.
You can even emulate Spotlight's "Spotlight Preferences" entry (or a "show all" option) by adding it last and setting its priority to required (1000) so it always stays put even if result entries above it are hidden due to lack of space.
Lately all my UI designs for 10.11 (and beyond) have been making heavy use of them. I keep finding new ways to simplify my layouts with them. Given how lightweight they are, they should be your go-to solution first unless you need something more complex (Apple engineers stated in WWDC videos they're intended to be used in this way).
Old 2011 Answer
This is private Apple API. I don't know of any open-source initiatives that mimic it off-hand.
Were I trying to do it, I might use an NSTableView with no enclosing scroll view, no headers, two columns, right-justified lighter-colored text in the left column, the easily-googled image/text cell in the right column, with vertical grid lines turned on. The container view would observe the table view for frame changes and resize/reposition accordingly.
Adding: It might be a good idea also to see if the right/left justified text (or even the position of the columns) is different in languages with different sweep paths. Example: Arabic and Hebrew are read right-to-left. Better to adapt than to say "who cares" (he says flippantly while knowing full well his own apps have problems with this sort of thing :-)). You can test this by making sure such languages are installed on your computer, then switching between them and testing out Spotlight. Changing languages shouldn't pose an issue since the language switching UI doesn't rely on reading a foreign language. :-)

Colored iCal style checkboxes using Cocoa

Is there a way to get colored checkboxes like in iCal without using custom drawing?
I have looked through the documentation but can only find how to change the background and text color.
You can achieve something at least similar to the colored checkboxes in iCal by enabling Core Animation for the checkbox and adding a "Hue Adjust" (in "Color Adjustment") content filter. If the color is static, this can be done entirely within Interface Builder, no code needed.
Be careful, though, as sometimes enabling Core Animation for various views causes strange bugs (for example, WebViews don't play nice with Core Animation views).
If you want to do it programmatically, take a look at the documentation for CIFilter (that's a link), which you use with the NSView instance method setContentFilters: (also a link).
It's a bit dated (runs back on 10.3), but Matt Gemmell published a some code for doing colored checkboxes a few years back.
http://mattgemmell.com/source
Look for "iTableView."
I looked at the code when it was first available, but not since. There might be a better way to do it at this point.
I'm afraid not. I'm not sure if the AHIG forbids this sort of thing or not, (it probably does), but the reason iCal gets away with it is because, 'Hey! Why not?'. Also, it's an Apple application, so yeah.
It can still be done, of course, but not without custom drawing. Personally, I'd advise against it, and rather see if what you are trying to achieve could be achieved some other way. If not, you could possibly use some of the data files from iCal to build your checkbox. (Unsure of how kosher that would be, but 'Hey! Why not?'.)

User interface paradigms that need changing?

Often times convention is one of the most important design consideration for user interface. Usually the advice goes to do it like Microsoft does.
This is for three reasons:
If it ain't broke, don't fix it.
If your users expect to click on a floppy disk icon to save, don't change the icon (even though some of them may have never seen an actual floppy disk).
Users don't want to re-learn the interface (and hot keys, etc.) with each different application they use.
At the same time Emmerson said "*A foolish consistency is the hobgoblin of little minds.*" So when does maintaining a consistent user interface cross the line from a good idea to stagnated innovation?
Microsoft shook up the good old WIMP GUI with the introduction of the tool bar, and then again with the Ribbon control (which is the natural evolution of the tool bar, like it or not.) Now we are seeing ribbons everywhere.
So my question is, what are some user interface paradigms that are accepted and consistent across multiple applications, but have stayed past their prime and are starting to reek? Are there some important changes that would benefit from a grass roots push by developers to innovate and improve the user interface experience for our users?
One thought that came to mind for me is the modal pop-up dialog. You know the ones that say: "Are you sure you want to . . .. - [Yes] [No] [Cancel] [Maybe]" and its evil twin "Successfully completed what you wanted to do! [OK]." We are seeing a movement away from these with the "info panel" in browsers. I think they need to be adopted in windows application development as well.
If possible please list a solution for each stale UI item.
And please don't list clippy. We all know he was a bad idea.
NOTE: This is specifically Windows client user interface paradigms, but I am certainly open to drawing inspiration from the web, the Mac, etc.
You mentioned popup modal dialogs , and I'd argue that non-modal ones are just as bad. Any dialog box remove focus from the program, they could end up behind the program and make it hard to find it, they might not even appear on the same virtual screen.
I'd like to see an end to all dialog boxes. If you need to stop someone from using the UI because of some non-normal circumstance, then remove the relevant parts of the UI from the window, and replace it with what the dialog would contain. Bring back the UI once the problem has been handled.
Clicking things on touch interfaces
It's incredibly difficult to click on things on a touch interface, because you don't know when you have pressed the screen hard enough. And if you add an animation to the button you are clicking, you most likely wont see it, because your finger is in the way. Adding other reactions, like vibrating the phone or painting waves on the screen might work, but there is usually a delay which is too large, much larger than the tactile sense of a button being pressed. So until they invent a screen with buttons that can be pressed, all touch devices should move towards dragging user interfaces (DUIs) instead.
Counter intuitively it is easier to press an object on the screen, drag it, and then release it than it is to just press and release it. It's probably because you can see the object moving when you start dragging, and you can adjust the pressure while dragging it. Dragging also has a lot more options, because you now have a direction, not just a point that you clicked. You can do different things if the user drags the object in different directions. Speed might also be used, as well as the point where the user releases the object. The release point is the real strength of DUIs, because it is very easy to release something, even with pixel precession.
Some designs have started to use DUIs, like (here we go) the iPhone, palm pre and android phones. But only part of their design is DUI, the rest is clicking. One area they all have in common is the keyboard. Instead of clicking on a key the user presses any key, then drags their finger towards the key they really wanted to click. Unlocking these phones also uses dragging.
Other easily implemented DUI features would be things like mouse gestures, where dragging in different directions, or drawing different shapes does different things. There are also alternate keyboards being researched which puts a bigger emphasis on dragging. All buttons can be changed into switches, so have to drag them down a bit to click them. With a well designed graphics, this should be intuitive to the user as well.
The Apple Human Interface Guidelines are a good read on this topic. They discuss this from a very broad point of view and the guidelines apply to any platform, not only Mac.
The file system. I want to save a file.. >OOOPs I need to think of a file name first. Well.... how about ... blah.doc.
6 months later...
Where the %#*(%& * did I save that %()#*()*ing file?
The solution is build a versioning system into the application, or better, the OS. Make files findable by their content, with a search engine, instead of forcing the user to come up with a memorable name, when all they want is for their file to not get lost.
Eliminate the save step. Type something in to the application, and it's just there, and there's no risk of losing it by some misstep, like forgetting to save. If you want an older version, you can just pick a date and see what the document looked like back then.
To build on the search engine idea: It's a pain having to navigate some arbitrary tree structure to find your stuff. Searching is much easier. However, you might still want to have something like a "folder" to group multiple files together. Well, you can build a richer metadata system, and have a "category" or "project" field, and setup the search engine to show items by project, or by category. Or group by those, or whatever new UI discovery we make next.
This question is a bit too open-ended, IMHO.
However, my main approach when designing anything is:
Fits in to wherever it is. If it's a windows app, I copy MS as much as a possible
It's simple.
It provides options
Buttons have a nice description of what the result of clicking will be, as opposed to 'yes or 'no'
Harder to answer the rest of your post without spending hours typing out an arguably useless (and repeated) set of guidelines.
In my mind, the one thing that really stands out is that USERS need more and easier control over the application's user interface appearance and organization.
So many interfaces can not be modified by the user so that the most used/favorite functions can be grouped together. This ability would make your favorite software even easier for you to get things done.
Error messages need a "Just do it!" button.
Seriously, I really don't care about your stupid error message, just DO WHAT I TOLD YOU TO DO!!!
I think the entire Document model of the web needs to change. It's not a user interface, but it leads to many, many bad user interfaces.
The document model was a good idea to connect a bunch of documents, but now the web is also a collection of applications. Today, I think the Page/document model corrupts our thinking. We end up lumping things together that aren't related, modularizing our code wrong, and in the end confusing users with our monolithic control board type websites.
Find dialogs that sit over the widget in which you are doing the search are terrible. Loads of apps do that. The find bar in Firefox works much better.
Many applications have multiple panes within the UI - eg in Outlook there's the preview pane and the inbox pane (amongst others). In these applications typically cursor key presses apply to the currently focussed pane. But there's very poor hinting to show the user which pane has focus and there are seldom keyboard shortcuts to move the focus between panes.
The focussed pane should be highlighted somehow.
Something like alt+cursor keys should move the focus around.
Ctrl-Tab and Ctrl-Shift-Tab cycle left and right through tabs instead of MRU behavior, even though in most cases the same behavior is duplicated with Ctrl-PageUp and Ctrl-PageDown.
There are a lot but here's an idea for a couple of them:
Remove some clicks like in "add another" or "search item" and the like.
This is well done with interfaces like ajax which have autocompletes ( and auto search ) but is slowly being adopted for platform UI's ( and in some cases they were originated in platform UI's. )
This is how StackOverflow does it for some scenarios.
But of course, we all know that already don't we? No need for "Seach tag" or "Add another tag" buttons, they just happen
Dialogs as you described.
Guys at Humanized proposed Transparent messages which actually are used in their product Enso and some other places.
Mac uses them for notifications ( like in Growl ) use them very well, or Ubuntu new notification system.
alt text http://blogs.sun.com/plamere/resource/NowPlayingGrowl.png
Firefox replaces the traditional "Search" dialog box with a search bar at the bottom.
Although not everyone likes the placement for next/previous as in this screenshot
And even SO ( again ) :) replace the notification with the yellow bar.
Finally:
File managers
I really like ( sometimes ) the simplicity of regular file managers, but some times I would like to work faster/better with them.
If you compare IE 4 with IE 8 you can tell the advance ( even better compare IE 4 with Google Chrome )
But if you compare Windows 95 Explorer with Win XP they are almost the same!! ( Win Vista/7 is a step forward )
But I wonder: Why haven't file managers improved as much as webbrowsers?
That's one reason I like stuff like QuickSilver but it is just a step. Much work is needed to create something like a "Perfect program launcher" or (FileManager/DesktopSearcher etc as you wish )
QuickSilver featuring "move to" action

Resources