the variation between browsers makes me think it's the browser itself causing the issue, not WD itself (speaking as a web dev, not a FM dev).
I've seen nuances like this in WD, but I have been using a self-practice of always setting up separate layouts for WD than for FM, due to the performance hit that WD can take in translating layouts. I use the same practice for FMGo as well.
I agree about seperate layouts for Go and Pro. Screen size and finger navigation versus mouse makes this a necessity.
This is a new DB and I tried to set up the Pro layouts with WebDirect in mind so it would use a single set of layouts for both. This is a simple list view required for both. it seems a shame to have to duplicate and optimize field position so that it look correct in both Pro and WebDirect. My approach for this was to compromise and have it be off a little for both. Looks ok... not perfect.
Found another gotcha when testing this with IE 10. I used the River theme, ( Client liked it..) It renders correctly in Safari, Chrome and FireFox. I know FireFox isn't on the approved list, but I tried it and it worked.
In IE 10 the border section with the vertical lines runs under the entire window, instead of just around the edges. For this, I'll recommend the use of Chrome.
Thanks for the suggestion
1 of 1 people found this helpful
I'm not sure it would work for you, but you could use the "Hide Object When" feature of FM13 to have an entirely different set of fields in each row of your list for WD vs. Pro, without duplicating layouts.
Not sure if this causes a performance hit on the WD side (IE, what does it need to render for the objects to know not to render them), but it would allow you to change field position on your list view based on connection method.
As a long time web developer, I've been dealing with IE nuances since IE4, so I feel you there. If you have the power to recommend a browser, then by all means I would recommend something other than IE.
That's an interesting idea. Seems odd to have two sets of identical fields offset a bit so that it renders correctly in a browser or Pro but could work. For the moment, I'm going with the compromise location.
On the plus side, portals don't seem to suffer from this as much. The fields seem to render just about the same in pro and browser. I haven't had to update any of these. I don't want to re-do these layouts, but next DB I may use portals instead of lists. This adds some other programming wrinkles but could work.
If you go the portals route, I would definitely think you'd be setting up separate WD layouts. At that point of time, it might just be worth it to adjust the list views. While I see your advantages in your case (UI compatibility), there may be hidden performance hits and other portal object quirks that might make it irritating for daily use.
This might work to your advantage a bit though, as you could most likely mask the layout fairly well (I forget if sliding portals are supported in WD), to lock the browser scroll bar, and force the use of the portal scrollbar as your "list" scroll. Having two scroll bars would be confusing from a UI perspective (IE users will always want to use the browser scroll bar to go down a list).
Sorry, now I'm just rambling.
Last night a friend sent me a link to Richard Carlton's video on developing layouts for WebDirect. http://www.youtube.com/watch?v=zS_8z9B95ic
It gives a lot of very useful information and definitely supports the practice of specific layouts for WebDirect. That stated, I think some of this could be applied directly to Pro layouts with good results.
I guess I took the devcon demo about how easy it would be to move a DB to WebDirect a bit to literally.
Thanks for your suggestions.
That is a great video. I had seen it when it came out but forgot to bookmark it. I think it should be required watching for anyone that wants to switch to WD.