 One of the reasons that I just asked you about where you are from is because I've always had a commitment to international stuff and the DS Benchmark free open source app which I distributed a year ago and which contains some of the demonstration stuff for this seminar, it is in multiple languages. If you look on the screen there we're really fortunate to have had volunteers translate it into Mandarin, Spanish and French because although I've got the privilege of speaking English as a mother tongue I'm really conscious of what a privilege that is because everyone wants to speak English and makes it very easy for us and you guys out there from other countries learning English it's not an easy language I know. My wife is Polish and I'm learning about Polish and that's actually even harder to be honest. Right, nine o'clock. So we've got an hour, 60 minutes to get through a lot of stuff. I'm not going to dwell on anything. I'm going to try and move through things quickly on the basis that virtually everything I show you will be in this app that you can download freely and the version I'm using here today will be on the relevant download page. I'm Nick Lightbody and we're going to be talking about building a high performance mobile custom app. The actual focus is on high performance and mobile first. We're not actually going to be doing the SDK thing but we're looking at all the stuff that is involved in making stuff fast. So I'm a comprehensiveist. I didn't know what that was until somebody told me I was that a few months ago but apparently I like doing a lot of different stuff and I get bored if I do the same thing for too long which means I have quite a wide view. You can tell from my grey hair I've been around a little while. I used to do international yachting and I'm going to put it on the right channel now aren't I? Okay that's better. I used to do international yacht racing before I did law and then got into FileMaker stuff in 1998. So I've been solving problems with FileMaker for 18 years and that's what brought me into it. My knowledge of the community is that probably 95% of the people in the FileMaker developer community came into it because they wanted to solve a problem and thought hey that's actually such a great way of solving a problem. Maybe I'll do it for other people too. There's a few people that I know who are computer science graduates and they're very very clever people and I couldn't possibly understand what they talk about a lot of the time. But the majority have come to FileMaker as a problem solving medium as opposed to a sort of computer medium. So let's take you back a bit of history. 1779 that structure, that amazing structure is Ironbridge in Shropshire in England. That is the first use of mass produced cast iron components to build a large structure in the world and that's the beginning, the basis, the foundation of the industrial revolution upon which the information age we are at the beginning of was built. And I suggest to you, although we're not all computer science graduates at all, I'd suggest to you in using FileMaker we are all engineers. We all are building machines, amazing machines often, with a zero cost of reproduction. This is staggering what we can achieve. And I suggest to you that in doing that we need to apply great thought, we need to try to achieve deep understanding, we need to experiment, to observe and to measure in order to get the performance we can achieve. I think that building mobile apps, they do have to be fast. If they're not fast, well user patience is limited. I mean it's, if something doesn't happen within a few seconds these days people will just go and go somewhere else. So poor performance equals no users so for me great performance is essential. And when you build a custom app, well there are different views on this, I'm probably a little bit controversial. In my view generally, but there are exceptions, you should build a single interface that works for everything. Trying to build different user interfaces for different devices is certainly possible, but it does make a lot of work particularly when you want to add new features you have to add them in various, the whole thing is fraught with difficulty. And the best way to make a good business is to find like a developer to create something that doesn't need a lot of support that works really well, I think. That's certainly the approach I've taken anyway. So moving on, what I want to do first of all is show you an example of what I mean by high performance. So I'm going to open DS benchmark on my iPhone. It's over cellular network, it's on a remote server, in this case it's in Santa Clara. We're going to search for a word and we're going to observe the results. So we're looking here, I'm going to press the button and swap. Okay, so we're going to look here, we're just going to open up DS benchmark. This has a standard opening procedure, which means it actually starts up in file maker server load mode. Okay, so this is starting up from scratch over cellular. Oh, thank you. Well, someone just mentioned us on Twitter, which is brilliant. Thank you very much indeed. I'm just going to go through that dialogue. So we'll get to the main menu here, having skipped the stuff that does all the charting and produces virtual clients on server in order to load server until it ceases to function in order to find out what server capacity is. This method of creating virtual clients on server is what file maker do internally, but they don't make their internal tools available to us, but you can use DS benchmark, it's free, it's completely open source. And if you can improve on it, my new request is circulate the community so we can all benefit from your brilliance. So DevCon 2016 examples, and we've got several here, but this is the half million post codes. Technically, maybe we can go sideways. Okay, that's better. We've got 574,000 records in there. They are post code areas from about nine countries around the world, because I like doing that sort of thing. I found some stuff on the internet a few years ago, assembled freely accessible lists of post code areas, and then did all the other stuff to process them to create various address databases. So I'm going to put in Santa Clara here. But I can put in anywhere else you want. If someone wants to look for somewhere else, we can do that. Santa Clara, done. See how long it takes to find the record. So it took that long to find 185 records out of 574,000 on a mobile device over a cellular network. Okay, this isn't Wi-Fi, this is cellular on a remote server. In my definition that is performant, i.e. it is fast enough for real people to use in the real world. So that's the sort of stuff I'm interested in achieving. Anyone want to give me a shout out for another place to look for just to make sure I haven't fixed this, you know? Give me a place, a small town no one's heard of, somewhere in the middle of nowhere. No, no, somewhere small. Red Bluff, okay. Red, second word, B-L-U-F-F, is that correct? Okay, done. There you go. It's in, there's two. One in Australia and one into Hammer County at California. If we open that, it'll take a little bit longer to open the Google Map because the Google Map is not the most efficient thing in the world, but it will give you a picture of, is that your hometown? Close, okay. So there you are. So that's what we've done with that. Right. So I'm going to swap back onto the laptop and we've done a demo DS benchmark. The result was we found N records quickly, from more than half a million on iPhone, on a cellular network. So my journey in trying to work out how to do stuff fast, I describe as a journey escaping from complexity. Trying to create simplicity and how, well, essentially my mantra, which I think has resonated a bit with some of the guys at FileMaker on product management, is I want to try and reduce everything I ask FileMaker to do. I want to ask FileMaker to do as little as possible because I'm going to get the best performance. I'll show you briefly something later on where FileMaker is the fastest means in the world of doing a certain thing, which is essentially manipulating text. FileMaker has a somewhat bad reputation that some areas are not always being performant. It's down to how you write your stuff. The actual technology will work very, very well, providing you understand its strengths and weaknesses and you work to do what it's good at. That is no different, frankly, to any other technology. So I'm focusing on the essential. Normally when I'm writing stuff, I write a certain bit of code, a way of doing it a script or whatever it is, a custom function, and then I look at it and think, well, how can I make it half the length? How can I get from A to B more quickly? And I just try and apply a little bit of rigor to reducing stuff down and putting in just the essential. About four years ago when I started on this path, I did a presentation to a couple of guys at Apple's offices in Cupertino, the then IOS user experience evangelist and another guy, and I started by saying the reason most features are in our apps are really, to be honest, not because users need those features, it's just because we can. And that's the thing in my view that you have to fight against. You don't put in the stuff that you can. You only put in the stuff that the users really, really need. That way your project doesn't take us long, quite frankly. So Ray Culligan. Ray is here this week. I haven't actually seen him yet. He's a bit like an apparition in Harry Potter. He's floating around, a great mind. He led an excellent class in London in early 2014. And what he did was he showed that whilst FileMaker the company focuses on how to do things, his class is all about trying to develop an understanding of why things were as they were. It's just changing it around. It's rather like, as I was saying about being an engineer, you need to observe, question, measure, analyse. And there's often better ways to do stuff if you go and look for it. So I have a considerable debt to Ray. He's a very clever guy. I've learnt a lot from him over the years. So the work I did over the last four years has ended up resulting in the DS app framework, which is what you saw a moment ago with a short demo. Stuff like this is all mobile first. It's all designed to work on a phone. It will also work great on a big screen because everything is completely flexible, and we'll touch on that later. It also led to DS Benchmark, which is built with that framework, which I've already said is available free and open. Here's an example on the screen of doing some load testing. This is where we would, I think from memory, we were running tests on FileMaker server 14 and 15 in order to compare them. At the bottom, you've got a chart created in two iterations of DS Benchmark running on the two different servers. Above, you've got the stats charts from the two admin consoles and two servers, and at the very top, you've got the computer activity monitor. This is on OS X on the two machines, showing the level of activity as those two machines are running with the tests running. We'll come on to the different tools you've got in a bit. So, as I said earlier, because of giving it away, this DS Benchmark is translated, and I just want to do a quick shout-out. Anyone who wants to tweet these or whatever, please do, because these guys do need our thanks. David Zhang at 33works.com in Beijing did the Chinese Mandarin translation. He was the first person to step up for Mark on that, and I'm deeply grateful to him. Later on, many of you guys will know Abraham Bitter in Mexico. He's done the Spanish version at iconsist.com, and he's also on Twitter now, Abraham underscore Bitter, and he'll be just so delighted to get a few tweets on that. Lastly, in French, Pauline Lefito, I don't know, she came through Big Tom in Japan. She's at apletronics.com, and she's done the French version. So, thank you very much, Chaps. I really appreciate it. I also published last year, Understanding Firemaker Server. It's a three-part paper. It's the first in-depth analysis of what Firemaker Server does, how it does it, how to get the best out of it, since, I think, probably Brian Dunning in about 2002. This is the paper that Firemaker themselves have never provided, because it actually explains how to get the best out of Firemaker Server, and that paper was written with very valuable input from Wymde Cwrt, from John Thatcher at Firemaker, from a number of other people around the world, and if anyone wants to improve on it, again, you're very welcome to give me your thoughts, and we'll make it even better. The high-performance work I've been doing has moved on to Despac CMS, and I'm going to show you that very, very quickly, and then we're going to start looking at some principles. In this case, we're going to open the app. We're going to create a web page, edit a page, and upload the page, and this is something which will then observe the results. This is something which Firemaker is actually faster at than any other technology anywhere in the world that I can find, and I think that's something that is potentially worth celebrating. I'll just get rid of some of these little things that are sitting in the way. When you come up here, you find that the resolution changes, and it's a funny old thing when you're working off a 13-inch laptop to see everything so big. Here is Despac CMS. I'm going to zoom it to make it a more usable size for us, and I'm going to put it there. I've got an activity monitor running down here at the bottom. All I'm going to do is to create a web page. I'm going to give it a web page. We'll just say DevCon Session. Prepare the page. There is the web page. If I just click Publish the page, that page will then be published on our server in England, and if I look at the live page on our server, it now looks like that. If any of you want to go to www.bolnell.com slash t slash dev3 slash devcon on a score session, you'll find that is there. We're now going to put some text into this. I'll just look on the web for something about maybe about DevCon itself here. We might just want to drop out of responsive design mode for a moment. Here is some text on the... I can actually select it. All right, just copy it like that. I'm just going to paste that text in there, add to end of page, and then rebuild the page and see what we get. I'll come back to the preview. We may have to change the color because we need some contrast. It's actually picked up a lot of stuff from that page because I selected the whole page rather than just a bit of text, but the basic point is I've actually taken the content of that page, put it on a web page, by just cutting and pasting it into a filemaker app. The filemaker app is typically building a new web page in a few hundreds of a second. To do the same thing with something like Pandox, which is where I started, will take 15 or 20 seconds a page. It's quite slow. Filemaker, in this case, is doing, amongst other things, is doing about 260 conditional local variable sets 260 substitutions through the CSS and then rendering a page and doing some other stuff as well, but basically it's mega-fast. I don't believe there's a faster way in the world of creating web pages this way, and I just want to make the point that Filemaker is a tool which can do stuff faster than anything else in the world if you do the right things with it. Okay, I'm going to flip back on to Keynote and move on. There you are. Back in my shirt says that, and it's true. If you use the Google page speech insight tool, which we may look at later if we have time, you can test any URL in the world. It will give you a speed rating and a user-friendliness rating, and find me another website that is responsive, that is faster than ours, which ranked between 92% and 98%, and I'll be delighted to buy you a beer. So, design performance. Many of you here will have read the paper that Mark Richmond wrote for Filemaker about two years ago called Design Performance. So, on the Filemaker website, there's a link here on the screen in the presentation, and it's our starting point today. That covered layouts in detail, looking at the importance of flattening themes. It covered schema, which I think is one of Mark's particular specialties, creating narrower table schemas, and it also looked at business logic and automation. So, we're going to build on this. We're going to try and do some stuff now, which is going to build on what you had in that paper. So, we're going to look at observing and measuring. We're going to look at layout design decisions. We're going to look at high-performance schema designs. We're going to look at advanced automation. So, first of all, who here has not heard of Bruce Robertson? Okay, well, a few of you. He's a very clever guy. He's given a lot to us. He invented virtual lists. If you look at the current Filemaker 15 training material, it does cover virtual lists. I'm not sure it credits him correctly. I hope they'll amend that. He's given virtual lists to the world, along with many other great techniques, and he's a man of considerable kindness, I think, to community. We're going to look at, very quickly, at the developer tools available in Savari and in Chrome. We're going to look at DS Benchwell, where we've already done it already, and we're also going to look at, very briefly, I'm going to remind you about the set of Filemaker server statistics and top-call logs that you've got to call on, and the activity monitor. Let's look at the clipboard analyzer tool. What it's doing is it's measuring the code required to define your layout, and the amount of code required to define a layout is going to control the amount of network load getting to your little device, and it's also going to contribute, obviously, the amount of processing that your device has to do in order to render the design. It is essential that everyone in this room knows to avoid local styles, but sometimes it's quite hard to spot. It's essential to flatten your theme so that all the local styles you create when you change things are reincorporated in the current theme. So let's take a look at this. So I'm just going to collapse this into the very convenient left-hand toolbar and open Bruce's little tool. Now, this is simple stuff. I say it's simple. He's made it look simple, actually. That's a better description. What he's done is he's using the base elements plug-in to do some clever querying of the FileMaker clipboard. So you need the base elements plug-in, the free plug-in, to use this. So all I'm going to do now is I'm going to open this FileMaker layout, the toolbar for Desperous CMS, in Layout Mode. I'm going to select all and copy. Over here, all I'm going to do is click Get Clip New Record. It says, do we want to get sizes? Thank you. We'll do that. So that's going to process that data and it's going to give us a result, which in fact I think is already done. That's pretty quick, actually. That's because the previous one is the same one when I was testing it last night. The difference is the date. The date was 20th yesterday and this one is today. So what's it got there? This has got 294,000 characters, I think. That's the FileMaker CSS that is used to define this particular layout. You can use this for any FileMaker layout or layout component or table or script or script steps. Anything you can put in the FileMaker clipboard, it will then measure for you. If you're doing it on the styles front, it'll then usefully identify if you've got any local styles. That's going to give you a little bit of a help to know where you've got to look. I looked at a well-known solution recently that's had some very good interface work done on it by a very good designer. I just, with the person who owns this particular system, said, let's just take a look at it in this thing. It took a while to process because there was, I think the layout was about four million characters of code to create it, so it took a little while to resolve, but it had, I think, about 23 local styles in it somewhere that hadn't been caught and hadn't been flattened. So if you want to avoid that network load of local stuff keeping on being downloaded every time a layout refreshes and never being cached, that's a useful thing. So this tool will be with my materials for this session. Bruce has given me permission to give it to anyone who's interested. I just say, if you find it useful, send the guy an email and say thanks because he's done so much for our community. So many people have made so much money out of his techniques and it would be nice to say thank you to him occasionally. Okay, so let's put that back into the right mode and go back to Keynote. Moving on. Safari developer tools. Safari has got a really nice lot of developer tools in it, which most of you will know, but anyone who doesn't know, you have to turn on the option in preferences to turn on the developer menu. When you've got the developer menu, you can then do stuff like going to design into responsive mode and look at stuff in responsive mode, get the tracking stuff here, which is showing you exactly what's loading. So if, for example, you're doing working web direct, you can see precisely what's happening. You can observe and measure how long certain things take. That gives you the ability to experiment perhaps with doing a layout in more than one way, comparing the performance of different components and deciding that for your purposes what will work best. So this is what I think is the route to getting better performance. It's not just guessing, it's not just reading a technique, it's actually doing your own observation and analysis. We've also got in Chrome, we've got a similar set of stuff, but slightly different. The particular thing I notice in Chrome is up here where you've got this option for network throttling. So if you haven't used that before and you're doing anything on a mobile device, then it's worthwhile looking at how your stuff works on, for example, a 3G network or an edge network and this edge being, I guess, in our terms, an edge case for whether or not it's viable on a mobile device. But those sets of functionality are really quite useful. So moving swiftly on because you guys, if you've not used them already, it will take you two minutes to work out how to use them. A quick look also, file maker server, admin console, statistics, top call log, et cetera. I'm not going to do that dynamically because it's too much of a hassle getting the admin console up during a demonstration. The first point to note, and you'll probably see this in other presentations, that there's the new element at the bottom here, the very bottom bit which is top call statistics. In FileMaker you've got three types of logging. You've got quite a few logs, actually, but basically there's the overall statistics that you see in the statistic interface about what's happening generally. That's based on log records and the logs folder in FileMaker server. So if you get the data, if you pull those logs out, drop them on to your FileMaker Pro app, you've got yourself a FileMaker database, you can then do stuff with it. Anyone who didn't, well not many people saw it yesterday, but Klaus at Data Manics who's done the upgrade on the file maker of the DevCon to Go app, Klaus and Peter Wagamans are working on a company called FM Whistleblower that he showed in the underconference session yesterday afternoon, and that's actually going to dynamically pull out all of these logs into a MySQL table with a FileMaker app in front of the MySQL to provide you with a viewport into final stuff you want and what's going on. So the key thing to understand is that if you actually look at these logs, don't just rely on the admin console interface, you can get a far better idea of what's happening, and as you go down into the next screen, which is the client, you've got the main tab here, you've then got the client tab where you can then pull up stuff on specific clients, and then you can go into the top call stuff where you can then look at individual calls and actually work out precisely which call is causing all that slowness, and that's the tools that you need. The other thing that's worth remembering is the Operating System Activity Monitor, which is currently running in the background here, I think, somewhere down here. I was surprised when I was doing some stuff with a leading purveyor of videos on FileMaker that he'd never realised that you could actually resize this thing. When it first opens up, it's very small, it's giving you one track for each CPU core or logical core, I think, rather than real CPU, because this is only a little Mac, a little PowerBook 13-inch. But if you use that as one of your tools for just watching what's going on, I normally leave these things running on the desktop, and any FileMaker server iteration I run, so if I just look at the desktop, I can just see what's happening, and then you obviously also have the ability then to look at the statistics, and if anyone's read any of my reports over the past several years on, for example, the amount of memory used by WebDirect, how much memory is actually using as opposed to what people think it's using, that's derived entirely from looking at the Activity Monitor on-server, pulling out the relevant processes, screenshotting them to record the RAM requirement over time. If I was cleverer, I'd obviously have worked out how to do that using the underlying logs which I've just talked about, but I never did that then. So tools, tools, tools. We've got tools to work with, so let's move on to some layout design decisions. Why use flexible layouts? Well, I'm a bit extreme on this. We'll talk about that in a minute. One window or many, there's the two big decisions on when you're deciding how to build your solution. Flexible layouts, fewer layouts, suiting a wider range of users, in my view, is a good way to go, but not everyone agrees. Some people feel that they want to have very big layouts for big devices, and that's your choice. However, less code, less complexity, less stuff going on, fewer layouts is something that can contribute to that sort of approach. Less development time. To me, that's good. Less maintenance. As I said a bit earlier, when you add a new feature, it's really a bore having to add it to all those different screens. So, that's another good point. How do you do it? Well, here's the thing. I actually realised how to do this. When I read Ray Couligan's version of the, I think it was Phalmicka 10 Bible, he laboured for about a year and a half, he writing the entire thing on his own, and I only realised how anchors worked when I read that. But I've been really surprised looking at stuff and really good developers, how many people still have static layouts. And I don't understand it really. We'll look at that very briefly. We'll also look at, you've got repeating fields. Repeating fields go back, press in some areas. In my view, repeating fields are one of the most wonderful aspects of Phalmicka. The reason for that is, you can have 32,000 repeats in any one field. Now, in Despace CMS, I'm continually adding additional numbers, basically, control windows, control fields, to control more properties in the CSS in Despace CMS. And that's it, I got 260, it started off with about 100. It's got more. Every time I want to add some more in, I didn't have to create new fields. All I do is go into the database define, and I say that my A3 underscore text field, I want some more repeats on it. And I can go up to 32,000. 260, I'll be very old before I get to 32,000. Those fields, those repeats, can all be dynamically addressed numerically, as we all know if you've used them. They also scale proportionally on a layout, which is very wonderful. And if you use repeating fields, your import and export scripts don't need any changes. Everything just works. You can add a thousand repeats in, your import and export scripts remain spot on the same, no hassle, everything works. So that's all good stuff. Button bars, obviously they will change proportionally, which is great. Portals and lists, so those are the full things that will actually respond proportionally or appropriately when a layout is re-sized. If I go back into DS Benchmark and just open any layout like that, go into layout mode, so that's, I'm just going to get this out of the way here in a minute. So what have we got here? We've got a very small layout basically. You can see that it's actually built to fit on a small phone with a little bit of vertical scrolling. The point is that when I go back into browse mode that can be as big as I want, obviously. Because who do it any other way? Everything scales nicely. And that's merely a question of using the anchors that you have for every object in an appropriate way, and using button bar, button bar, button bar. There are no repeating fields here, but there are another layouts to do that job. So I merely say that in my experience it's a far easier way to work and you can probably save yourself some time to work in that way, but it isn't for everyone. But one thing that fits lots of things, I think that's good. One window or many? Okay. This is a really big question, and I don't know who here builds all their stuff with only ever one main interface window? Okay. And who always has many interface windows? Okay, and the rest of you presumably do a bit of each. The point is, as you will know, if you've done many, there are a number of challenges with many interface windows, but also there are challenges with single UI windows, and I'd suggest that they're the same. First of all, though, we need to remember that mobile devices will only apply well, in WebDirect, will only display one layout window in WebDirect or in Pharma could go. So when you're aiming for that type of stuff, multiple windows may not be appropriate, or it may, but it's a key thing. WebDirect, obviously, only one layout window on not-so-mobile devices as well. The big issue is the record-locking issue, isn't it? Because if you have multiple windows open, you can often have multiple windows open on the same record. If you have a single UI window, you never have that problem. But a single UI window may mean you need to have many more layouts. If you take an example, if you've got supposing you had sort of four different bits of layout stuff you needed to use. If you have them each in a separate window, you can just view whichever ones you want, whenever you want them. But if you are going to make bigger layouts with two or perhaps three parts in them, then you may end up with multiple different layouts with different combinations of those layout components in them for different purposes, different uses. So you can find that using a single UI window ends up meaning you have to create far more layouts. Far more layouts, as I said earlier, equals far more maintenance when you want to add a feature or change things. What I do, and I've done this recently, I was talking to Steve Dolenski over there a few months ago and he said, oh, he said, you need to do that. And I said, I completely agree, Steve. And here's the one I did a few weeks ago. He's probably been doing it for ten years though. I discovered it recently. So let's just quickly look at that, because it uses a file maker function that I'd actually not used before. I need to find what are we on here? We're actually on something else, aren't we? Open remote. We're on that one there. So there is a function that will give you essentially the saved state of your record and it has three saved states. One is that nothing is uncommitted sorry, naught is nothing is uncommitted. One is a new record with uncommitted stuff and two is an existing record with uncommitted stuff. So if you look at this, my apologies for not having started this on here so I could do this first. I'll just give you a moment to do some social mediaing or breathe or I do also apologise everyone for speaking in a foreign language here. I'll do my best to keep it clear. So I'm going to open my script maker and I'm going to look at this one here. So this is called commit. Now we're going to have to zoom this, I think. Do you know what? I should be in that one there. Here we are. Commit all windows. Just zoom that. So we are going to cycle through all the open windows and commit any that are not committed. Setting a couple of variables and maybe make it a little bit bigger. The key point is that we are only going to commit ones where the record open state is greater than zero. And most people know this if you've done this, if you haven't. It's like all these things. You design your stuff so it never does anything that you're going to have to do and clearly you're not going to need to do this unless you're doing this method of having multiple windows. So what we're doing is we're calling this script whenever we get an error. So if we try to edit a field or something or other, we get an error saying that we can't because somebody else is doing it with an automatic called that script which just cycles through the open windows and commits everything. And it pretty much solves the problem. Moving on. High performance schema designs. Mark Richmond said entirely correctly very adroitly that it is really a good idea to use narrower tables. The reason that's a good idea is that whenever you open a record in FileMaker all of the data in all of the fields in that record other than container or material data will be moved from the surface of your device. So if you are displaying one field on your iPhone and in that record there is another field with a million words in it all of that stuff will come up to your iPhone before well it'll come up to your iPhone basically it'll be a ton of network traffic. So what Mark said is have multiple one-to-one relationship tables. So you're on if in your current thing you need to have 300 fields in your main data table why not have multiple tables each with some of the fields in. So you're then breaking it up and you're only taking that chunk of data when you want to display something because it'll only do it for the table. So it'll display the record it'll upload to your device the data from the fields for the record in the table you're in. I've just taken that to an extreme. So what I've done is I've created very narrow tables exceptionally narrow tables with just one data field I've then used virtual fields within the very narrow field and I've also drastically reduced indexing. We're also going to look at lists for the portals for performance terms and chunking of data. So the first basics though we've already said we need to keep things simple we know pharma gas to value it and cash everything it sees whenever anything happens so we need to try and reduce that reduce what's happening and the basic starting point for most people in this is to use some sort of UI that's based on a UI table on UI records that has very little data in it and then it's only going to take you in through portals or through lists on other layouts to data when you actually need it. So step one for everyone and this will be everyone already does this I'm sure is when you land on a system you land on a system with very very land on a layout based on a table of currents with very very few records. You reduce the number and complexity of your fields although your client may say they need a thousand fields maybe you can normalise it maybe they actually need to have a join table with a subsidiary table with a very simple structure and those fields in the subsidiary table can be in different types maybe they could have 300 different types maybe their 300 fields that they want to have could be in a join table could be through a join table in another data table with 300 types of a very very simple narrow field that will work so much faster if you give FileMaker a really narrow table it'll blaze Basics again reduce indexing now FileMaker as a default says create on any given field it'll create index as if required now I never give normal users access to FileMaker find mode I always do it in something that I think is a simple and friendly way. Developers need find mode you never know what you're going to do but an ordinary user you can predict it but the moment you're into find mode and try and find a field it'll then create an index for it and if you look carefully at stuff there are tons and tons of indexes on fields that nobody ever looks at so what I say is turn off all the indexing and then only turn on the ones you need to make stuff work so one method of this is what I say using the display title and search summary model is that in my stuff which is in DS benchmark you have a field called record title and that's the one that's always displayed on the tables, top of the record whatever it's just an auto entered field that you can adjust the expression in to show whatever you want to show from the underlying record but you only ever display that field it's one field which can then be displayed as a field variable secondly you've got a second field which is the search summary which again is auto entered from whatever else is in the record but you only ever search on that field so you turn off all the other indexing except obviously the indexing required on key fields and so on and you just search that one on the field now it doesn't give you quite the flexibility of finding a fine mode but in most cases it does everything you want and if you add in a tagging system then you'll find it's pretty easy so that's the sort of thing that I'm talking about so single day table architecture I'm not saying you should do this experiment is just showing what you can do if you make stuff super narrow so one table one key data table many types of records and the advantages are you only have one data table to back up you only have one data table for which to build services you only have one data table from which to export and import data what we do and you can see again in DS benchmark we then have underlying tables of different types which are automatically populated for the key data table so the key data table has got all the actual data in it when you edit the record that table gets changed but then the underlying tables automatically ought to enter and change and that then gives you the ability to call on specific fields and specific circumstances in different ways I'm not going to go through all that but it's all there in the thing you can look at it and I'm happy to discuss stuff because I find it interesting to learn how to do this stuff better it's a really scalable way of doing because once you've got a very simple structure you can then of course make multiple versions of it and anyone who's read my paper on file like a survey you'll have seen the term there is resource contention which is what people normally refer to as contention there's also in my view solution contention which is where your solution or pinch points where lots of users hitting the solution are actually all hitting at the same point generally it's making records in the same table so one of the weaknesses of this approach with a single data table is when a lot of users are hitting with making lots of records they are all hitting the same table and that will create solution contention you can then dynamic, you can then have more iterations for subgroups etc the further experiment was ultranarotables and this is putting all the data in a single text field and dynamically adding field names to it again this is not for everyone I'm not saying you should do it but if you bear in mind this is feasible and possible and can work very well it's another option to consider this means, this came out of apple notes when I started using apple notes about four years ago I know it's become a little bit more sophisticated now essentially it was a place you could write stuff in I thought wouldn't it be cool if I could actually have different values in that big text field being different fields if on a certain type of record the first line will be the date second line will be the client third line will be the charge code so I then built a system which achieved this so that the field can be just somewhere you write stuff every record is related or can be related to a project and a client so you can just write anything you want in there or you can use the field method and you can put in these virtual fields so you can then put things against specific field headings and it means you have great flexibility all of us if you work at anywhere near knowledge workers knowledge workers spend their time putting their information in fields were never intended for the purpose because the field they want isn't there that's why they end up with so many fields with this method you can have far fewer fields and give far greater flexibility it's very fast let's look at the DS benchmark relationship graph to give you an idea of how this is structured so let's make that a bit bigger I try and keep my relationship graphs and I'll then zoom it a bit as well so I try and keep my relationship graphs again like a mobile thing so I can scroll vertically I don't like going too wide I find it gets to be a bit boring trying to find things but at the top you've got the main UI various stuff that relates to it we won't bother exactly now but you can look at it in the app it's all there, it's all open but the main UI stuff is at the top and over on the left here we've got some stuff to do with tokenisation and so on then below the main red bar we've got three main groups of table occurrences we've got the CD one creating delete we've got the hierarchical one so what we're doing there is whenever we want to create or delete a record we're doing table occurrences in that group because there's a certain load that arises in these areas and my feeling is it's a good idea to keep it in a separate place so the ability to create several records through joins etc is all in there we then got a hierarchical method where we have a limitless parent child system which means that you can then just create records as children of other records and create a great big structure if you feel like it on the right we've got the all one and that's what we saw when we looked at the half million records and that obviously gives you all now a few years ago I was trying to work out how to pull together data from various tables you could search in one place and it was quite complicated but what I've done here is by having a single table data structure it means when you search the old table you're searching all types of records in one place that means you're searching your entire system in one place and that's very powerful you don't have to tell the user to go to a certain place to go and find clients a certain place to go and find projects is all there you must move on because time is running against us and we've really talked this through already basically reduce field indexing is very fast if you only index what you need it's great and maybe one day FileMec will have some features that help steer first time users away from indexing everything inside their system gets bigger and bigger and then they start hitting some performance problems list feed portals which is the best to use in any given circumstance let's compare the characteristics of each portals give more control if you use keychains you do however you do it but in a portal you can control who sees exactly what but they are much slower for sure lists in FileMec of these days are staggeringly fast and again you saw that earlier in our whatever it was 100 or so records out of more than half a million just like that you can restrict the number of records that the user gets through the relationship and that actually speeds up portals if we have a portal looking into half a million records but the user's only got access to a few hundred or several thousand then the performance of that portal will be very much better so it's horses for courses there's no absolute answer that one's better than the other it depends on what you want to achieve lists give less control for a start if you're using the FileMec security model properly you may have all sorts of records coming up saying no access no access no access no access and wouldn't it be nice if if you had no access to the record you couldn't actually see the record that would be really very cool indeed actually but at the moment you have that problem I don't believe you should ever have users seeing that type of stuff I think it's bad for the user experience but they are very very much faster than large data sets so the correct decision depends on what you want to achieve the chunking of data now this is a way that I evolved a couple of years ago to enable me to use portals where there's very large numbers of records because of the problems we just touched on so what we're doing here is we're creating a value in each record which I'm calling a legion control merely a legion because the Roman legions I believe had a thousand soldiers in each and in a conversation with Richard Carlton a year or two back we both agreed that these portals and things they run up to two or three thousand records perfectly happy is when you get over that it starts really not being so good so we thought why don't I put in a means which is then use the relationships so when the user opens the thing or does their search then you get the first thousand records bit like on the internet generally in web things you go in the file maker community and you get 25 records and you click if you do that it means that you get the first screen coming up fast then they ask for more they click the button for more you change the code you then get more records so it's a way of making users a better experience by avoiding them having to wait now it is true that under 15 the portals perform better and this technique is less necessary than it was in the 14 but it still seems to pay and again that is all in there but I'll show you very quickly um you just need to look at a couple of um fields so I need to go into there and look at the data field and we need to find the right one down here somewhere and then zoom it so for example if you look in the thing they use Legion as part of the name in this particular case we're using the get next serial value as the method of creating that key Legion control number I tried various methods but if you hang it off file makes ability to create serial numbers very easily then that's the best way that I could find and if you see here where we're saying get number left L-3 we're taking the thousands part of the serial number to give us the Legion number for this record ok so that's that's where we are on that but it's all in there you know what to look for in the file now and you'll see it in the relationships in all that you've got um a control number which controls the um the number of legions the number of thousands down the list that are permitted to come through the portal in the relationship for the portal the last section is advanced automation services scripting I've covered this because it seems to me a lot of people aren't using it particularly well and um I haven't seen many people writing about how to use it well some people obviously know it inside out so a few strong pointers here we're also going to look at menus very quickly and creating a language layer which will be very very fast so you need an effective version and what I do is I write stuff to run locally and then I run it server-side and I have a script that switches automatically depending whether or not we're on server but also which has got a manual switch so I can then simulate being on server the big issue obviously is that everything has to be passed through the script parameter and you've got to have a method of doing that there is a method written by um Alan Sterling from London who's another very clever chap I owe a great deal to in this version there's two custom functions he wrote as a simple way of passing many many parameters and passing them out again of the of the script parameter and then you need to debug you need to look at the server log the server log in the admin console is going to give you errors when anything isn't quite right on your server-side scripting plus you need to create your own event log to essentially create records from the session now the point to know is that when you call a server-side script it creates a unique new user session on the server and the file startup script will run at that point so you need to design your file on the script so that you don't actually have all that stuff running when you have a server-side call otherwise you get chaos so that's the first big gotcha for most people who haven't explored this deeply or perhaps who've tried and haven't got too far once you understand that and once you've structured your scripting your startup scripting to accommodate that which again is your own DS benchmark then we can do this so we'll look at a couple of things here we'll look at sub-new user and a couple of custom functions so if I look at sub-new user first which should already be in the script editor if I'm in the right script editor which is that one there okay so that's what we want at the top of this script we've got some comments which are actually documenting the enclose functions this is Alan Stirling the beginning part of his little custom function so using x enclose to take variables in the calling script and give them these particular labels and then we're going to take that data out again but we're passing all of that stuff in single script parameter I call it the data baton for the want of a better word like a relay race we're passing it through to we can see over here parameter $sp script parameter $sp on those two scripts the upper one is performed script on server the bottom one is doing the thing locally and we then got the x run on server switch which is telling it which one to do so if you run this file on your local machine it'll run locally if you put this file on a server it'll run on server because clearly if you have in your local file a performed script on server function and no server it ain't going to work doesn't okay and we've also got this thing called s-mode which is just a switch so you can simulate this on a local machine so my recommendation to you is if you're doing server side scripting use this sort of method as a way of organising yourself and you'll find that it gets a lot easier and I'm going to just show you a couple of custom functions at the moment in a case that file maker don't have a function that actually tells us whether we're on server or not so this is the way I do it at the moment get application version and if the left hand six characters of server means I know I'm on server other people do it in similar ways you might use a pattern count instead but this is very simple because you need to build into your structure something that tests to see if the wretched script is on server or not because you've got to do that you've got to be able to control it and tell it which way to run okay and then if I go back on to there and reduce our zoomingness menus text is very fast, low load is efficient you can easily choose the language on some menus which can use a security model which is very very good great advantage you can add new things in your system in the menus you don't have to edit any of the layer it doesn't need to put on more buttons very good it does have some limitations so it's a great way of doing it another way is using table driven menus which is what I've done and this gives you an infinite accessible parent child method and it's very fast and it also gives you ability to use multiple language support so if you look at the model in ds benchmark so if I go into ds benchmark which is going to be there um we need to go into manage and the menu table and we probably need to make this a bit bigger don't we again you can see how it works when you look at it but here you've got a table where all the menu items in this app are in this table and if we move down you'll recognise some of them from what you've already seen the xa3 description item is a calculated field which is getting that value from the global language item for this particular menu so if we change into another language all of these will change the bit I draw your attention to though which is the bit that I'm not that I wish to be proud of anything because everything I've done is just built on what other people have done but I was quite pleased with is this bit here these numbers if you look at the key numbers in this column here what happens is depending on the number of digits you put in you can make something a child of another record so for example if I say that this item here s4 legion chunks make it a bit bigger ok if I change that if I put a one in there and click outside it that will then make that the child of a record which is 5, 6, 4 if I change this one to 5, 6, 4 click outside that one right now this has now got three ellipses after it showing it's got children so now when I do that when I click on lists or portals when I get lists or portals it tells me it's got children and this item here is now in the submenu of that merely by changing the numbers there ok it's mega flexible I built this thing about two and a half years ago I've never changed it since it can do everything you want it holds things like layout but the basic point is it's very very flexible and that for me is what I like ok so I'm just going to go back into here and creating a language layer this is displayed using global variables I've written about this on the file maker form in the past we put each language in different repetition and I'm going to show you now how we do that again in DS benchmark so if we go back to this editor we had the menu editor and now we've got the language editor so if I want to call in here I don't know records say like that here are all the language items that include the characters record in the global variable that's used in the interface or in the data behind it so what happens is look at the top one here dollar dollar are you sure is what is actually in the interface so if you've got a button to have this word these words on it you put dollar dollar are you sure on the button here is what it says in English are you sure you wish to leave this record oblique these records if I then go and look at another language I'll get down here the same thing in French ok or in Chinese or in Spanish I think somewhere Portuguese wherever we're taking the language and publishing it to global variables and we're using global variables throughout the interface on buttons on layouts in menus anywhere you want nowadays even on the tabs you can use global variables and it's very fast there's about 300, 299 records in this table at the moment publish them I click that button and it's done it takes I don't know a quarter of a second to republish all of that language to those global variables again you look at this it's done I've written about it on the family community about a year or two ago I think to be high performance you have to respect people's needs to do stuff in a language that they understand and I don't assume that we all want to work in English the whole time that would be really idea so that's very very quickly how we do language I would commend to you doing dynamic multiple language systems because you've got a great app you sure as heck are going to have a bigger market for it worldwide if you've got it in Spanish as well and other other languages and then going back to our presentation virtual lists worth exploring you've probably seen about it before I just commend it to it's a really really great technique very powerful so we're a few minutes over my apologies but we've built or endeavoured to build on farm makers design performance guide we've looked at observing and measuring we've looked at layout design decisions we've looked at high performance schema designs we've looked at advanced automation particularly server side scripting of course and the file that I'm providing you has got all of this stuff in it except I think for one item which is in another file but you've got all of that any questions you can come back to me afterwards thank you now and thank you also to Bruce Robertson to my daughter Helen Lightbody at RGA who gave me some very good pointers on mobile when I didn't understand mobile very well Ray Culligan, Chris Moyer Ian Smith, Richard Colton Wimdekaw, John Thatcher, Rick Helman have all contributed in these ways to what you've heard from me today so I'm Nick Lightbody and you can find me in various social media platforms here here here and here I am at Nick Lightbody on Twitter I think so you can find me on that as well there will be updates and question and answers please step forward to the mic and ask your questions a few minutes now before we have to vacate I'm happy to take anything you wish to wish to put in my direction thank you I would say has keeping you know that the evaluation sheets are very very important and there is a new method being used this year using survey monkey or some monkey or primate or other apparently due to a glitch in that system when people are using that every time they put in a new evaluation the previous one they've done so a lot of evaluations in the first two or three days of this event have actually been lost so the word is if you can remember what you went to try and go back and put evaluations and I believe that the survey AP is now working correctly and isn't equal to your evaluations but if you can find the time then please do make the effort and please do do do give some feedback on this particular event and if you like it enough maybe they'll ask me back next year okay thanks very much indeed