Skip to main content

Fieldbook: Spreadsheets on Overdrive

UPDATE: FieldBook is shutting down as of June 15th, 2018. Their co-founder, Jason Crawford, has written a great article on medium describing the reasons why.  It's always tough when businesses shut down but it is valuable to learn why. It looks like finding and engaging resources is always a challenge.

Business owners and workers all over the world build applications using spreadsheets. When funds are low or time doesn't permit, a spreadsheet can be the starting point for a new business application. It's fast and easy. Even in larger corporations, workers take to Excel to make up for what their IT departments couldn't or wouldn't give them. Microsoft has done well with this - Excel has grown from a basic spreadsheet to a full application development system. Microsoft may offer Access or SQL Server Express but to the chagrin of many developers (and sales folk), Excel can be used to create not just workbooks with protected cells, but fully form-based applications that hide the specific worksheet structure and produce results, all under the familiar Office flag.

While one can easily argue that Google sheets and Excel in Office 365 brings the spreadsheet to the web, they do so as a calculating engine. Fieldbook takes the business aspect of the spreadsheet interface and builds it on the web while maintaining that spreadsheet feel.

You start by building a (work) Book and book has (work) Sheets. Rather than decide the structure first, as you might with a system, the first sheet starts with columns, waiting to be filled in.


This puts the focus on the data. Data purists may balk at this - but as I noted last week, it's about the business problem - NOT the theory. Thankfully, Fieldbook starts seeing the patterns that emerge as information is filled in. Columns with only numbers are automatically totalled. Not only that, but as soon as a value starts with "=", it immediately recognizes that we're building a formula.



Now that the data has been entered in, a structure starts to take shape. Click on a column header to change the name. Fieldbook KNOWS you are building an application so based on what you type, it suggests the column name.

Columns are defined by 12 different types. Aside from the obvious String, Number, Currency, Checklist, FieldBook offers special types of email, web site and Day of Year.  Day of Year is entered as basic text or number and then it transforms to values such as 12/25. 

Picklists are also an available type. Here, Fieldbook really excels (no pun intended) at transforming a simple spreadsheet into a useable business application. If you choose a Picklist, the list automatically defines based on the values previously entered. But if the list needs to be coming from a dynamic table, Fieldbook offered "Linked Sheets". Choose a type of Linked Sheets, and the entered values are put into a new "Sheet" and the field now becomes a choice pick list. Changing the type is as easy as choosing it from the list.



With column types, Fieldbook has easily transformed a basic spreadsheet into one with some business smarts. Can you get into trouble with this flexibility? Certainly - but it's no different than with applications going through growing pains where fields that were intended for one purpose are, in fact, used for another by the business. Fieldbook has shown itself adept at getting information entered in a spreadsheet format but where it shines is in making it easier to work from. Click the double-arrows and the rows turn directly into a Form.


The Search box in the left corner is also the tool for making Fieldbook work for you. From the Search box, rows can be grouped, sorted, and filtered. Once set, searches can be saved for easy retrieval.

Now that you've got a spreadsheet, Fieldbook makes it easy to share. While others can be invited to create an account in Fieldbook and have read/write access to your books, a direct link to a given sheet can also be shared. When the link is shared, anyone can access the sheet in read-only format. If changes occur in the sheet, the link automatically updates.

But better, if you share a "form" (which can also be customized), it becomes HTML code that can be embedded onto a web site and the information will be entered into the sheet. The forms may not be elegant (it would be nice if you could do multiple columns) but it sure beats having to share a spreadsheet with someone.



I've seen a number of clients asking users to fill in a spreadsheet and then having to reconcile multiple sheets when users have re-arranged columns or entered invalid data. What does this really mean? You can create a form for other users to enter data on a web page or its own link, using your rules of lookup and formats, and the information is put directly into your book, without having to add user accounts. Customers or employees can enter information without knowing where it's being stored and your book is automatically updated. You want to track results from a quick survey? Do it in Fieldbook. Fieldbook would make a lot of lives easier with shared forms.


While you can customize the forms and create filtered and grouped lists, Fieldbook doesn't have a lot of other views. Its strength is in its feel as a spreadsheet. It's as easy to use as....actually, it's easier to use than Excel and Google Sheets, especially as a business tool.

For developers, Fieldbook offers an API as well as integration through Zapier. The API works as JSON and can be used for web hooks, direct API calls and scripts known as Codelets.  The strength of Fieldbook is in the user interface so developers can focus on the integration and special functionality that can't be figured out by the business owner.





As with pretty much all web applications, pricing is per user per month. Fieldbook is $10/active user/month. But it's free for basic usage - you pay when you need to have more advanced functionality. I really like Fieldbook's approach to usage - you pay based on usage. Your organization may have 10 users but if only 5 people use it within a 30 day period, you are only billed for 5 users.

My biggest complaint about Fieldbook is its lack of a native mobile application. You can definitely use its web version on a tablet and a phone but it feels a bit lacking. Still, when businesses are familiar with spreadsheets and you don't want to spend a lot of time or money to create a useable solution, Fieldbook definitely fits the bill.


Comments

Popular posts from this blog

Blogs and RSS come to Microsoft.com

MS has just introduced their portal and it's pretty comprehensive. Nothing quite like learning that some people use AIM instead of MSN messenger, or that there really may be a need for supporting 4 monitors ( Cyrus Complains ) However, it's really a great sign that MS is serious about supporting the blogging community which seems to have um, exploded in size in the past year. Blogs and RSS come to Microsoft.com

Elevating Project Specifications with Three Insightful ChatGPT Prompts

For developers and testers, ChatGPT, the freely accessible tool from OpenAI, is game-changing. If you want to learn a new programming language, ask for samples or have it convert your existing code. This can be done in Visual Studio Code (using GitHub CoPilot) or directly in the ChatGPT app or web site.  If you’re a tester, ChatGPT can write a test spec or actual test code (if you use Jest or Cypress) based on existing code, copied and pasted into the input area. But ChatGPT can be of huge value for analysts (whether system or business) who need to validate their needs. There’s often a disconnect between developers and analysts. Analysts complain that developers don’t build what they asked for or ask too many questions. Developers complain that analysts haven’t thought of obvious things. In these situations, ChatGPT can be a great intermediary. At its worst, it forces you to think about and then discount obvious issues. At best, it clarifies the needs into documented requirements. ...

Programmers vs. Developers vs. Architects

I received an email this morning from Brandon Savage 's newsletter. Brandon's a PHP guru (works at Mozilla) but his newsletter and books have some great overall perspectives for developers of all languages. However, this last one (What's the difference between developers and architects?) kind of rubs me the wrong way. Either that, or I've just missed the natural inflation of job descriptions. (maybe, it's like the change in terminology between Garbage man and Waste Engineer or Secretary and Office Administrator) So maybe it's just me - but I think there's still a big difference between Programmer, Developer and then of course, architect. The key thing here is that every role has a different perspective and every one of those perspectives has value. The original MSF create roles like Product Manager, Program Manager, Developer, Tester, etc - so every concept may pigeon hole people into different roles. But the statements Brandon makes are often distinction...