#webviewer

Caveats

Users must have an internet connection since this is a web font.

RawGit has no uptime or support guarantees so this should not be used for mission-critical solutions.

Product Support

In my testing, this works successfully in:

FileMaker Pro on Mac

FileMaker Pro on Windows

FileMaker Go

WebDirect on Mac  (tested on Mac FMServer)

WebDirect on Windows: Chrome only (tested on Mac FMServer)

Custom Web Publishing (as with any web font)

I did not get this to work in WebDirect in Edge or IE on Windows (Mac FMServer) but I didn't try to troubleshoot it. I leave that to you — and please reply below if you find a fix! :-)

The version of FileMaker shouldn't matter, although the OS version might, since web viewers use the browser engine that's native to the OS.

The demo

Download the demo   (no email registration necessary!)

I've put comments in the FileMaker file.  Basically, we need to define the @font-face(s) in the CSS, linking to the hosted version of each font you'll need. In my testing, Mac needs only the .woff version of the font and an abbreviated grammar of the CSS, but Windows needs more.  Instead of trial-and-error-ing until I found the right combination, I just used the full code from the example from the font’s creator.  If your solution is cross-platform, use the full code since it works on both.

Usage

The values in the sparkline need to be whole numbers from 0 to 100 and must be nested between curly braces { } , separated only by commas. Lucky for us, FileMaker gives us plenty of ways to compile our data into this structure.  

The values then need to be placed inside an HTML element that has the appropriate CSS class attached. Inside that element you can also place the first and last values—on either side of the curly braces—which will be output in the sparkline font (instead of any other font you might be using in that web viewer).

<span class='sparks-dotline-thin'>{10,20,45,70,90}</span>

<span class='sparks-bar-medium'>10{10,20,45,70,90}90</span>

About sparklines

*Sparklines were developed by Edward Tufte (yay!), who described them thusly:

A sparkline is a small intense, simple, word-sized graphic with typographic resolution. Sparklines mean that graphics are no longer cartoonish special occasions with captions and boxes, but rather sparkline graphics can be everywhere a word or number can be: embedded in a sentence, table, headline, map, spreadsheet, graphic. Data graphics should have the resolution of typography.

- Edward Tufte, Beautiful Evidence, 46-63. (scroll down)

And you can find lots more uses and examples of sparklines around the Internet.

About web fonts

**Web fonts:

Web fonts allow Web designers to use fonts that are not installed on the viewer's computer.

- Wikipedia

UPDATE: This is my fastest blog-post-into-irrelevancy turnaround yet.  Per Daniel Wood's comment (see below), none of this Web Viewer stuff is necessary :-P  Still, maybe you'll find some of the techniques here of interest, even if not appropriate in this situation.  Or just carry on with the rest of your Interwebz.  Thanks, Daniel ;)

Download the demo file (.zip)  The Slide Panel buttons are on the top right.

What I did:

Placed a Web Viewer onto a new Panel of the Slide Control (so as to keep the original) and made it the same size and position as the original element

Set the Web Viewer to use a Data URL and set the CSS for the background to be the same gradient used in the original

Selected each button, opened it in the Preview app (via File>New) & saved it as a JPEG Normally I'd just use CSS for buttons, not images, but I wanted to make this (quickly) like the original

Created Base64 strings of each button image via an online Base64 image converter

Changed double-quotes in the Base64 image tag to single-quotes so there's no need to escape them

Wrapped each Base64 button inside an <a> element (for a clickable link), set the href attribute to an FMP URL, and placed them on the Web Viewer

Created a GoToLayoutByParameter script to be called by the FMP URL

Set the CSS for the images so they would center and be positioned like in the original

The FMP URL:

"<a href='fmp://$/" & Get ( FileName ) & "?script=GoToLayout&param=LayoutName'>"

What I noticed:

This worked well, and the Web Viewer did indeed block the behaviors of the underlying elements (on-hover visual changes and clickable buttons), however I discovered that the contents of the Web Viewer didn't render until the full panel was displayed, which meant that the background gradient and the buttons weren't visible during the sliding animation :(

What I changed:

Created an additional Panel of the Slide Control

Set the Web Viewer itself to have the same gradient as the original element (as opposed to the default solid color of white)

Placed copies of the button elements on top of the Web Viewer so they display during the slide animation (Once the Web Viewer is rendered, these buttons are hidden underneath) The images aren't perfectly lined up, but it's good enough for the demo.

What I think:

Well it ain't perfect.  The copies of the buttons on top of the Web Viewer in particular feels inelegant & kludgy.

Is it an improvement on the non-WebViewer versions?  Dunno.

Please see Responsive FileMaker Design & Web-Viewer Layouts ( the trailer ) for more details, the inspiration, and a screencast video showing how to use the file, etc.

Caveat

There are still some issues that I wish were better dealt with when using these techniques, which is the main reason I never updated my demo file until now. My main frustration is that the protocol can only be used on a given computer in either FileMaker 12 *OR* 13, not both. So if your computer is set to use the FMP URL protocol with FileMaker 13 and you try to use an FMP URL in a database open in FileMaker 12 (or vice versa), it won't work. It may try to open 13, but won't have the context from which it was initially run. For Mac users, there is a downloadable preference pane that can be used to select the default application for the FMP URL, although this doesn't remove the problem of 12 *or* 13. This problem also exists on Windows. I haven't tested this, but maybe it can do something similar. Either way, it's a real drag that we can't just trust that a solution we build using Web Viewers and the FMP URL will work for all users -- without the possibility that they may need to download & configure something just in order for it to work.</rant>

Demo = (a) Web Viewer interaction + (b) "Responsive"

As a brief review, there are two main components to this demo file:

It uses a Web Viewer, the FMP URL protocol and JavaScript to read from and push to the underlying FileMaker fields.

The layouts are "responsive"—using techniques from "Responsive Web Design"—which means a single layout adapts to screen sizes from iPhone (FMGo) to desktop.

These two components don't need to go together, but it was really the "responsive" part that pushed me to experiment with all this in the first place.  However, since the FMP URL is the thing that's changed with 13.0v2, that's what I'm focusing on in this post.

Overview  (fmp:// URL, called by JavaScript, on Responsive "Web-Viewer Layouts")

The data-entry layouts contain only a Web Viewer.  The web viewer uses a Data URL that inserts the relevant field contents into <input> elements within an HTML <form> element (like a form you'd fill out on a website). As you navigate through the records, the Web Viewer is updated with the data of each record.

When you submit a change to the data — either via the Submit button or by hitting Return/Enter on a regular keyboard or touching "Go" on the iOS keyboard — JavaScript sends the contents of all fields, along with their respective field names, as a single parameter to an FMP URL that then calls a "PerformEdit" FileMaker script on that record. This FileMaker script in turn parses the parameter into name-value pairs (field name & field value) and then uses the Set Field By Name script step to update the record.

The JavaScript

NOTE: You do not need to understand or modify this JavaScript in order to incorporate these techniques into your database.

$('form').submit(function(){ var str = $('form').serialize(); var encStr = encodeURIComponent(str); var replStr = encStr.replace(/%3D/g,':::').replace(/%26/g,'|||'); $(this).attr('action', '" & FilePath_cf & "?script=PerformEdit&param=' + replStr ); });

Basically, when the form is submitted this grabs all of the field names and field contents and places them into one text string. It then encodes that string to be "URL-safe" and then replaces the specific "=" and "&" characters that define the key-value pairs in that encoded string with other text strings to make things easier on the FileMaker side

Here are the three versions of the string before it gets sent to FileMaker as the fmp:// parameter:

1) As captured via the jQuery serialize() method [ var str ] :

NameFirst=Jane&NameLast=Doe&Company=Doe+%26+Doe&Address=123+Main+St.&City=San+Francisco&County=&State=CA&ZIP=&Phone=(415)+555-1212&Fax=&Email=jane%40doedoe.com&Web=jsfmp.com

2) Having passed through the JavaScript encodeURIComponent() function [ var encStr ] :

NameFirst%3DJane%26NameLast%3DDoe%26Company%3DDoe%2B%2526%2BDoe%26Address%3D123%2BMain%2BSt.%26City%3DSan%2BFrancisco%26County%3D%26State%3DCA%26ZIP%3D%26Phone%3D(415)%2B555-1212%26Fax%3D%26Email%3Djane%2540doedoe.com%26Web%3Djsfmp.com

3) And then swapping some strings via the JavaScript replace() method [ var replStr ] :

NameFirst:::Jane|||NameLast:::Doe|||Company:::Doe%2B%2526%2BDoe|||Address:::123%2BMain%2BSt.|||City:::San%2BFrancisco|||County:::|||State:::CA|||ZIP:::|||Phone:::(415)%2B555-1212|||Fax:::|||Email:::jane%2540doedoe.com|||Web:::jsfmp.com

You can see in this last iteration, the ampersand character that divides the key-value pairs (as seen in the initial version of the string) has been replaced with "|||", yet the ampersand entered in the Company field, "Doe & Doe", retains its standard URLencoded string "%2526".

The FileMaker Script

The FileMaker script first decodes the JavaScript-encoded string (step 2, above) via a custom function.  It then replaces all occurrences of "|||" (step 3) with pilcrows (¶) so that the one long text string becomes a list of key-value pairs, with the field name and the field value separated by the ":::" string.  The script then just loops through all these pairs, and uses the Set Field By Name script step to update all fields:

Set Variable [ $vals; Value:Substitute ( URLDecode_cf ( Get ( ScriptParameter ) ) ; "|||" ; "¶" ) ] Set Variable [ $fieldCount; Value:ValueCount($vals) ] Set Variable [ $i; Value:1 ] Set Variable [ $error; Value:0 ] Set Error Capture [ On ] Loop Exit Loop If [ $i > $fieldCount ] Set Variable [ $parseKeyValuePair; Value: Let ( [ _row = GetValue ( $vals ; $i ) ; _pos = Position ( _row ; ":::" ; 1 ; 1 ) ; $fieldName = Get( LayoutTableName ) & "::" & Left ( _row ; _pos - 1 ) ; $fieldValue = Substitute ( Middle ( _row ; _pos + 3 ; 9999 ) ; "+" ; " " ) ] ; "" ) ] Set Field By Name [ $fieldName; $fieldValue ] If [ Get ( LastError ) <> 0 ] Set Variable [ $error; Value:Get ( LastError ) ] Exit Loop If [ 1 ] End If Set Variable [ $i; Value:$i + 1 ] End Loop If [ not $error ] Commit Records/Requests End If Exit Script [ Result: $error ]

Using the demo;  Incorporating with your own data

The demo contains two separate layouts that both interact with the FileMaker data as described above:

A generic template layout, named "SomeLayout", which any FileMaker user should be able to modify and use with their own data.  As demonstrated in the video on the original post, you only need to place the relevant fields onto a standard FileMaker layout (with the appropriate naming convention; in this demo it's "SomeLayout_fields") and the Web-Viewer layout will place all those fields automatically into the web form.

A "customized" layout which uses significantly more complex CSS, JavaScript and some HTML5 — to give an example of what could be possible for developers with more web development skills.

Both layouts are Responsive. And with rumors of a larger screen coming with the iPhone 6, this could be another good reason to use these techniques over separate layouts for each device/window size…

Download the Demo File

This is the same file from my original post; cleaned up a bit, unlocked, and still happily not perfect :)  

In fact, navigating records natively in FMGo13 now looks very odd in the "Customized" layout because of the slide effect — so I'd probably remove the Status Bar on a production file like this for FMGo.  Also,  Internet Explorer 9 does not support columns in CSS so on Windows with IE9, the template layout is always just one column. There are other options if you need to support IE9.

Get it zipped (.zip) or unzipped (.fmp12) (for FMGo)

And remember to check out my original post to see more of how to use this file.

Other possibilities…

There are a number of additional advantages to using "Web-Viewer layouts".  Because the whole interface is essentially a web page, you could incorporate almost any web technologies into a Filemaker interface. Pretty much anything you've seen on the Web (specifically in Safari &/or Internet Explorer, since those are what run FM Web Viewers) could be brought into FileMaker.  Think of user-friendly web forms with instant field-validation, hints, "masks" that only allow the input of certain characters (e.g. "(___) ___-____" for U.S.-type phone numbers, in which typing a letter character won't even display), etc.

Also, because the styling of the layout is done via CSS in a text field, you could potentially open up modification of layouts to anyone with edit-access, including in FileMaker Go!

FileMaker 13 has brought in some great new web-like UI features such as hiding elements, popovers and slide controls, but there's still plenty in the world of web design that can only be implemented in FileMaker via Web Viewers.  And now since 13.0v2, there's very little reason (see Caveat, above) not to start implementing them now.

*Other FMP URL examples: http://www.filemakerbloggen.se/post/a-clickable-map http://www.isolutions-inc.com/?p=1727 http://www.soliantconsulting.com/blog/2014/04/getting-started-javascript-and-filemaker http://www.seedcode.com/filemaker-webviewer-javascript-calculation-engine  & my "A web-like UI for DevCon2Go (2013)" from last year's DevCon

Please add additional examples or resources in the comments.