Symphonious

Conversion for the Web

2009-11-04T11:20:33Z

Andrew Shebanow in Open Government and PDF:

The issue at hand is not whether governments should pick HTML or PDF. The issue at hand is whether governments are capable of publishing information at all. Show me an HTML creation tool that creates high quality, standards conformant markup from a Word document or any of the zillions of editing tools that government employees use. Now add in all the tools used by people who submit documents to the government. And all the versions of those tools released in the last 20 years. Now make sure that the HTML/XML works correctly even when the user doesn’t have the right browser or the right fonts installed.

I’ve actually worked with a number of government departments who were looking to move more content online and the content conversion problem is definitely a time consuming and challenging part of the problem. That’s precisely why I wind up getting involved, since EditLive! lets you easily copy and paste content from Word documents and produce clean, compliant XHTML. It can even (optionally) strip out inline formatting and leave just the structure like headings, tables and lists.

Furthermore, EditLive! is actually quite good at making sure the HTML works correctly even when the user doesn’t have the right browser or the right fonts installed, especially when it’s been configured to suit the particular content needs. Even with non-technical business authors this can work very well and is doing so for a significant number of government departments.

That’s not to say it’s the whole solution, there are systems out there where it’s hard to convert the content to HTML and where HTML may not be the best format anyway. Some of those cases may work better with PDF but certainly not all of them. To somehow suggest that PDF is a complete and simple solution to publishing information on the web misses quite a lot of the picture. For example:

How do web site visitors navigate around and get to that PDF data? How do they search and find it? As much time is spent working out navigation structures as it is converting content.
How do you expose information from databases with regularly changing information? Wouldn’t a HTML representation be easier to generate than PDF in most of these cases?

Putting information on the web is not simple and no single technology is going to make it simple. PDF definitely has it’s place on the web, but so does HTML and a number of other formats. PDF doesn’t alleviate compatibility concerns, not all users have a recent enough PDF reader, not all PDF embed all the fonts and when they do it makes the download very large etc and not all PDFs are standards compliant. Putting non-web stuff on the web is always a big, challenging project, so review the available technologies carefully and pick the ones that best achieve your goals. Very few companies have success with just dumping a whole heap of PDFs on a web server.

Don’t Blame The User, Blame The Editor

2009-10-23T09:50:05Z

I swear, some days you just want to reach into the screen and strangle the blogger on the other end. Jeff Atwood complains that his users commonly fail to read all the helpful hints on how to use their overly complicated, what you see isn’t what you get editor on Stack Overflow:

The ask question page is already dangerously close to cluttered with helpful tips, but apparently these helpful buttons, links, and text are all but invisible to a large segment of the user population. Sure, you could argue that Super User tends to attract less sophisticated users, but I see the exact same problem with programmers on Stack Overflow. As new users, a significant percentage of them can't figure out how to format code, even though there's not only a toolbar button that does it for you, but help text on the right explicitly describing how to do it manually. (Just indent 4 spaces. Spoiler alert!)

So essentially, users don’t find the editor intuitive and the solution they’ve gone with up until now is to add more and more help text to try and teach the user how to use the unintuitive editor. It’s not working. The obvious solution is to escalate the arms race:

More and more, I'm thinking we need to put the formatting help — for new users only — directly in their line of sight. That is, pre-populate the question entry area with some example formatting that is typical of the average question. Nothing complicated. But at least then it'd be in the one — and apparently the only one — place myopic users are willing to look. Right in front of their freakin' faces.

Thankfully the comments are full of people suggesting the right answer – fix the editor so you don’t need instructions to use it. You can always provide a source view for geeks who like to type in markup, but make the default something that just works.

If the mark of a poor tradesman is that they always blames their tools, the mark of a bad UI designer is that they always blame the users. It’s not them, it’s you.

Using Scala in .NET

2009-10-19T14:28:28Z

Having become quite interested in languages that support deployment on both Java and .NET, then diving into Scala to find it’s a good language, the obvious next step is to try using Scala on .NET. I found a little time over the weekend to try that out with good success. Notably, I haven’t tried this in a real project yet so there may yet be some significant catches, but so far it looks really quite promising.

Simple .NET Exe

First things first, let’s write some Scala then compile it to a .exe file that uses .NET. Our scala class is the simple Hello World:

import System.Console
object test extends Application {
  def main(args: Array[String]) = Console.println(“Hello .NET World!”)
}

Note that I put this in a file called test.scala as part of my fiddling to make this work – I don’t think that should be required but it certainly doesn’t hurt.

Compilation to .NET requires two steps. Both are best performed by opening the “SDK Command Prompt”1. This looks very much like the normal Command Prompt but it defines a bunch of important environment variables so that all the .NET tools are on your path and working correctly.

If you haven’t already, as the Scala docs say, copy the mscorlib.dll file from the .NET SDK (I had to use find to locate it then picked one of the results at random) to the %SCALA_HOME%\share\scala\lib directory
Again, if you haven’t already, install the scala-msil support by running:
```
sbaz install scala-msil
```
Then compile to the MSIL intermediary format with scalac-net2:
```
scalac-net test.scala
```

Now you should have a test.msil file alongside the test.scala file. The next step is to convert the file to an actual EXE file with the ilasm tool3:

ilasm test.msil

Now you should have test.exe alongside your test.msil and test.scala files. Before you run it though, you’ll need to find the predef.dll and scalaruntime.dll files in the Scala distribution and copy them to the current directory4.

Finally, you can now run test.exe and see “Hello .NET World!” printed.

Creating DLLs for Visual Studio Projects

The same tool setup can be used to create DLLs for use with Visual Studio projects. I created a C# web application project in Visual Studio, then modified my test scala class slightly:

import System.Console
class test extends Application {
  def getStuff) = “Hello .NET World!”
}

Then recompile it with scalac-net as before. Since we want a DLL instead of an EXE file we add a /dll parameter to the ilasm invocation:

ilasm /dll test.msil

Now we’ve got a DLL ready to go. I copied the three DLLs, test.dll, predef.dll and scalaruntime.dll into my Visual Studio project to make them easy to access. Then:

Right click on the project in Visual Studio
Select “Add Reference…”
Click the “Browse” tab
Select the three DLLs you copied in.
Click “OK”

You can now access your Scala class from C# quite easily. I edited Default.aspx and added:

<%= new test().getStuff() %>

Code completion even worked. Running the project correctly shows “Hello .NET World!”.

Stuff Yet To Discover

There’s a lot of stuff I don’t know about yet, largely because I’m starting from pretty much no knowledge of .NET programming, but also a few Scala related things:

Unlike Ruby and Python, Scala doesn’t have a class library that’s designed to stand alone – it somewhat assumes the Java libraries will be there. Things like IO are left to the Java classes so they’d need to be abstracted away with separate Java and .NET implementations. It remains to be seen how limiting that could be.
- Worse, I’ve seen some blog posts mention that not all of the Scala library is actually available on .NET. The XML libraries directly reference a bunch of Java IO stuff for example.
You can combine multiple classes in one DLL. When I still had test as an object, I got ‘test’ and ‘test$’ put into the DLL. When I have multiple .scala files to compile I’m not sure at what point or how they all get combined into one DLL. I’m guessing somewhere along the line putting all the files as arguments should do the trick. Otherwise it will get pretty unwieldy.
I’ve got no idea what actual deployment of this stuff is like. Last time I touched .NET that was a complete nightmare even without Scala. Hopefully if the project references all the Scala DLL files they will get bundled up in whatever way Visual Studio would normally do when preparing to distribute.

1 – I believe this was installed along with the .NET SDK 2.0 package I grabbed – I didn’t notice it being installed with just Visual Studio but I could be wrong. ↩

2 – scalac-net seems to be a handy little wrapper around scalac that sets -target=msil and adds the right DLLs to the classpath. ↩

3 – this is the part that really requires the SDK Command Prompt and the environment variables it sets up.↩

4 – I think under Windows DLL loading rules they can actually be anywhere on the PATH. ↩

Getting Into Scala

2009-10-15T15:23:16Z

When I was in Australia visiting Ephox’s awesome engineering team recently, it was suggested that we should be seriously looking at using Scala for some or all of the server side development we have coming up. The key benefit that was described to me was based on productivity – I certainly think that has merit but I’m somewhat more interested in it being a potential solution to the new cross platform problem 1. Options like JRuby and Jython are also a possibility in this space, but Scala fits more nicely into a Java programmers mind-set and is designed with the JVM in mind, so while it pushes a lot of boundaries, ultimately it fits with the JVM and Java very nicely2.

So I read through the O’Reilly Programming Scala book on the plane ride home3, then jumped in and built a small but real-world project with Scala and integrated it into a Java servlet project. I think it’s given me a pretty good grounding in what Scala can do, the benefits it brings and the general state of play.

The Language

The Scala language is fantastic. Easy to learn if you have a solid programming background and just a smidgeon of functional programming knowledge4. I’ve always been on the fence between compile time and runtime typing, but I think Scala strikes the perfect balance. It’s strictly typed at compile time, but uses a lot of inference so you don’t have to constantly declare types. I quickly came to find that there are two places where it’s incredibly handy to always specify types:

Parameters. Scala requires it anyway, but it is vital documentation for anyone who wants to call that method.
Return types. Not usually required by Scala, but by being explicit you can catch quite a lot of weird errors that crop up and isolate them to the right method. If you leave the return type as inferred, the compile error you get usually comes out on the caller of a method and can be somewhat confusing. The most common error here is effectively not returning something or returning two different types by accident (usually because you expected a different return type from a method you called). This isn’t hard and fast – short, simple methods are usually best left inferred.

Having closures is definitely handy, but the benefit isn’t really in closures themselves. What really makes a difference is the libraries designed to be used with closures5, and the functional programming style that comes naturally in Scala. Looking back at the code I’ve written, the structure really looks like something that would make sense as a mathematical equation – each method does one thing, consistently and without side-effects. More importantly though, the breakdown of methods that results winds up being quite logical and helps reusability a lot. I find that getting the split points for methods right in Java is much harder and requires more conscious thought.

Traits – wow do I ever love these things. The first key benefit I found for them was unit testing. In Java, one class would tend to be responsible for loading and processing it’s data. In Scala, traits make it so easy for the class to declare an abstract variable for the data and just provide the processing. Traits then step in to provide the loading part and provide a concrete implementation of the variable. It becomes obvious to have a LoadFromDatabase trait, a HardCodedString trait or a LoadFromFile trait – now where the data comes from is clearly separated. In tests you just use a HardCodedString trait and there’s no need for Mocks or Stubs.

Interestingly, there is a wonderful synergy between traits and JNDI. Traits can’t accept constructor arguments and even if they could it’s ideal to just declare that you want a new Widget() with DatabaseLoading and have it just work. JNDI gives you that ability – the DatabaseLoading trait just grabs the datasource from JNDI and there’s no need to tunnel parameters through to it like you would otherwise.

I’m also a big fan of the uniform access principle that Scala uses. Essentially, from the caller’s perspective, there is no visible difference between accessing a public variable and accessing a public method. So you can have a base class that declares an abstract variable, then implement it with a concrete method in a subclass and visa-versa. It’s an incredibly simple concept that gives a lot of flexibility and avoids a ton of boilerplate code.

The Tools

This is the weak point of Scala, but it shows some promise.

Testing Libraries

There are actually quite a few testing libraries in Scala – all of them somewhat difficult to get working inside an IDE or Ant build, but all quite solid and stable if you use their test runners. The xUnit equivalent is ScalaTest, I never got it working with Ant or Eclipse so gave up and moved on to Specs. I love it6. The Aussie dev team recently switched from CamelCase test method names to using underscores7 for readability, but Specs takes that a few steps further by letting you use strings. For example:

“Administrator users” should {
    “have a password at least 8 characters long” in { …code goes here… }
    “be in the admin group” in { …code goes here… }
}

The test output is really easy to read using the Specs runner, but it gets much less readable when using JUnit to run the tests via ant. You can avoid the outer ‘should’ block which helps readability in JUnit but it’s still not great. Fortunately, IntelliJ has support for Specs directly and lays things out pretty well, plus the normal runner isn’t bad.

Standard Toolchain

The Scala distribution comes with a good set of tools. A scala command for executing scripts and scalac for compiling classes are the main two. Both work really nicely and the scala tool is particular good for experimenting with things – especially when you’re trying to learn the type inference system.

The single biggest drawback is that scalac can’t compile Java code, so you can either have Scala code depending on Java code or Java code depending on Scala code, but can’t do both easily. This isn’t all bad, as it really encourages you to break the project down into independent libraries and reduce coupling but it would be nice to more easily mix languages.

IDEs

Wow, these are terrible. The Eclipse plugin is incredibly buggy and is practically unusable. NetBeans seemed to work well but is very short on features. IntelliJ has a good set of features but has overall stability issues since you need to use an early access build of the IDE – the plugin itself seems quite stable. IntelliJ also has some support for Specs and ScalaTest rather than having to run them through JUnit which is quite nice, but it didn’t seem able to just find all the tests in my project and run them – it was limited to one package at a time. Getting Scala working in IntelliJ is an absolute nightmare and you’ll spend forever searching Google for answers. There are magic libraries you need to put in place and very cryptic error messages if you don’t have them – at least it’s a once off. Once the Scala plugin works with a released version of IntelliJ I think that will be the winner, otherwise I may have to deal with NetBeans8.

Java Libraries

They work really nicely, except that Scala doesn’t use the normal java.util Collections framework. Scala has it’s own collections framework with equivalents and they are dramatically better but it does make it difficult to inter-operate with Java libraries that use Java Collections. Fortunately, Scala provides wrappers for the Java Collection types to make them act like Scala collections, but it doesn’t have wrappers for going the other way. It’s definitely not the end of the world, but does make you think a bit more about where the Java to Scala leap should be – sometimes writing a few key classes in Java can make things dramatically easier. Judicious use of implicit conversions, a scary but powerful feature of Scala, can be a big help too.

I do like the ability to specify values in Scala as @BeanProperty and have the compiler automatically generate JavaBean compliant getters and setters (or just getters if it’s a read-only value as is common in Scala).

There can also be problems with tools that manipulate bytecode since the bytecode Scala generates is compliant with the JVM specs, but often quite different to what javac would product.

The Performance

I can’t tell the difference between Java code and Scala code. That’s roughly what other people are saying too. There are an awful lot of classes that come out of Scala code because of all the closures and traits and the like so it’s not going to work if you are tight on space such as in applets. Server side where processes are long-running and JAR size isn’t a critical concern, it will work perfectly. I would guess9, that there are a very large number of short-lived objects being created and discarded with Scala due to the use of implicit conversions and all those closures, but garbage collectors are so heavily optimised for that use case that I can’t see any evidence that it makes a difference and the performance testing I’ve read about bears that out.

The Scala compiler implements tail-recursive optimisation and even supports an annotation so that you can mark a method as tail-recursive and get a compile error if it’s not.

In terms of scalability – Scala advocates claim that functional programming and immutable data structures that are heavily used in Scala are a key tool, if not the solution, for scalability. I don’t know and don’t really care – the applications I’m likely to write will fit nicely into the “scale by handling many requests at once” model rather than having to break up the work of each individual request over multiple threads. The problem will come in the database or web server level, not my application code. I’m watching Tim Bray’s Concur.next series with interest though.

Overall

Scala is very much a tool I’m glad to now have in my toolkit. It’s not yet ready for prime time purely because of the poor IDE support, but it is excruciatingly close. I can see me advocating it’s use in Ephox quite heavily if it deploys to .NET smoothly as the cross-deployment is a massive benefit and would be worth the pain of sorting out the tooling, but it would be hard to justify if that isn’t viable yet – especially given the potential for Ruby or Python to work on both J2EE and .NET.

I don’t think it will be long before the Scala toolsets catch up and it becomes an extremely compelling option for Java server-side development.

1 – it remains to be seen how stable/useful the .NET version of Scala is – I’ve been focussed on the Java side of things for now ↩

2 – this adds to the scepticism around the .NET version until I find time to really test it out though ↩

3 – yay for power points in cattle-class ↩

4 – a few months of Haskell in uni counts if you paid attention. In fact, Haskell is a particularly useful background to have as it is a very pure functional language and uses a similar static typing with inference system as Scala does. ↩

5 – thus I question how useful closures would be in Java ↩

6 – Actually, I think ScalaTest can do the same style of tests but I got Specs working first. ↩

7 – sacrilege! ↩

8 – I love the concept of it’s ant based build system, yet somehow the implementation drives me nuts every time I try to use it ↩

9 – I’m too lazy to profile this at the moment ↩

A Great Team

2009-10-01T09:42:02Z

I’ve spent the last couple of weeks in Australia for my baby sister’s wedding and while I was there I worked out of Ephox’s Brisbane office where our engineering team is based. It’s been nearly 18 months since I left there to move over to the UK and this is the first trip back since. What was most striking about the trip is just how awesome the team is down there. Technically speaking they are one of the most talented groups of engineers you’re ever likely to come across and pull off some seriously amazing stuff, but more importantly they are a truly great team.

Engineers are known for being anti-social but you don’t see any of that in the Ephox team – they all get on well, love the work they do and work as a team, not just a group of individuals. Everyone in that team should be seriously proud of the culture they have built up in that team.

For those non-Ephox folk reading this, you too can join the team as Ephox is currently on a serious hiring binge in a number of areas. Check out the jobs page for details.

The New Cross Platform

2009-09-25T06:40:59Z

When I first started professional programming, Java was reasonably young and was being hailed as a work of genius with it’s cross platform deployment capabilities. Programming was going to be revolutionised forever and all programs would run on any OS1. Then Java wound up being most popular on the server side and liberated server code from the choice of OS more than the desktop side2.

Server OS’s started to compete mostly on how well they were a server rather than what programs ran on them because what really mattered was that you could run the Java stack. In other words, Java became the platform that people deployed their applications to. It shouldn’t come as a surprise that a single platform didn’t stand unchallenged for long. .NET sprang up as the big enterprise competitor to Java and all of a sudden you had to choose sides again.

The interesting thing is that another layer of platform abstraction is starting to spring up. Languages like Ruby and Python came from a background of running standalone and are now starting to abstract away the choice of the Java or .NET platform, just as Java abstracted away the choice between Linux, Windows or Solaris in it’s time.

From what I can tell, none of the languages have really developed a fully complete, heavy production ready, bet-the-company-on-it implementation for both the JVM and .NET but both Ruby and Python seem to come very close and have serious corporate sponsorship behind them. Right now the sense I get is that people are either using Iron Python or Jython, Iron Ruby or JRuby but not seriously deploying the same code to both. It doesn’t look like it will be long before doing so would be quite feasible though.

Exciting times ahead.

1 – Interestingly enough this has actually been the trend, but not because programs were developed in Java – it just inspired developers in other languages to build cross-platform abstraction libraries. ↩

2 – albeit not as smoothly as anyone would have liked↩

Are Web Pages Still Safe?

2009-09-03T18:51:35Z

The relentless addition of cool features in HTML5 is getting a lot of web developers excited and there’s really no doubt that it will be a huge step forward for the web. The more I follow the WhatWG mailing list though, the more I think we’re long past the era where it was considered safe to visit web pages. I’m not talking about browser security holes which have been around for a fair while and certainly do pose a risk, I’m talking about the things that are actually by design.

There’s nothing seriously threatening, just an ongoing increase in the amount of power and the amount of knowledge that web pages get. For example, it used to be possible to store a tiny amount of data in cookies in a way that was considered transient and ok to delete at anytime. Now you can store up to 5MB and there’s a strong argument being made that it should be considered user critical data and not easily cleared like cookies. In another thread people are asking for notification when the user has been idle for a period of time – great for chat applications and the like, but expanding what web pages can track about you1.

In my mind there’s a mental model of how dangerous things that’s something like:

Static data is like an jpeg image or a plain text file. You read it but it doesn’t do anything active – no scripting nothing dynamic at all. It could still trigger a buffer overflow or some other security hole in the software you’re using but otherwise it’s inert.

Active data is like a web page with some simple JavaScript that modifies the page.

Sandboxed Applications are like iPhone applications. In theory they should be contained and safe, but you should still think carefully before installing them because they’re real applications that while limited can do actual damage. On the iPhone that actual damage involves unrestricted access to all your contacts and the network among other things.

Applications are pretty obviously anything else. While most systems these days put restrictions on them in some way such as file permissions, they are essentially unrestricted.

The web started out as static data, then when JavaScript was invented became active data. When GMail came along and people worked out how to really leverage JavaScript it moved to somewhere between active data and a sandboxed application2. People want to build real applications on the web, which essentially means they need to keep being pushed along that progression. The only problem is that as you increase the abilities of web pages, you also decrease the safety, not just because it’s a bigger attack surface, but ultimately because the more a web app can do, the more likely it is that you want to have control over it.

I’m left wondering if it’s possible to create a UI that lets users choose exactly what applications can do, without either confusing them or much worse, bombarding them with permission dialogs. Flash certainly failed miserably at it – if you ever turn off local storage in flash and try to browse the web, you’ll find it almost impossible to use most flash programs because they just repeatedly ask for permission to store data. Facebook and most other web apps that allow third party access fail at it too – if you install a Facebook app it gets access to pretty much everything. I’m sure in theory and maybe even in practice they could have more fine-grained permissions but the UI never makes them obvious and I’m not sure it could.

The plus side of all this, is that so far the main issue is really that users are losing their privacy, but as web apps want to do things like monitor folders for new files or any of the other niceties that desktop applications can take advantage of3, it’s going to become more and more of an issue. How are we going to ensure that clicking a link is still safe?

1 – Currently they can only tell if you are using your browser or not, if you switch to another application they can’t tell if you walk away from your computer or if you’re busily using a different application.↩

2 – Depending on the plugins you have installed and if you approve special rights it could be completely unrestricted of course. ActiveX made a mess of that model, causing major security problems in Internet Explorer and has since been put behind a lot of scary warning/approval processes.↩

3 – and the Chrome OS is certainly going to be pushing the envelope very quickly in this area↩

Stop Suffering in Silence

2009-09-03T08:49:32Z

I keep seeing otherwise intelligent people1 encounter problems with software but never actually report them to anyone who could fix them. For commercial software opening a support ticket takes just a few minutes and usually gets the issue resolved pretty quickly so you can stop wasting time suffering through it or complaining about it. For open source software it’s often a bit more difficult – you need to join the users mailing list and ask questions there, follow up if you don’t get a response and maybe even put together a solid bug report. Still nothing ominous.

Of course, the opposite effect happens too. Once someone finds they can report an issue and get it fixed for them, they often go a bit crazy reporting things – even before they’ve done a bit of investigation to confirm they’ve place the blame on the right bit of software2.

I’ve been watching both these things happen within Ephox lately and it’s amazing how many things you can get solved quickly when you do get the right balance between reporting too soon and reporting too late (or not at all). It’s a skill I think we need to work to improve.

1 – Myself included sometimes.↩

2 – I’m sure there should be a good quip about the bug being in your code rather than the library/compiler/OS/etc but I can’t find one.↩

The Point of Surveys

2009-08-28T07:37:31Z

Every so often while using NetSuite, it pops up and asks me to fill in a quick little survey – basically how likely are you to recommend NetSuite and why? This is annoying when your in a rush but on balance not a bad way for them to ensure their customers are happy.

There’s just one catch – every single time I tell them that I’d never recommend NetSuite and that they should improve product quality, specifically they should handle escaping XML tags correctly. As a company that makes HTML editors, we quite often send and receive emails that talk about HTML tags rather than just including them. Unfortunately, NetSuite for the past 5 years or more has happily messed these emails up and we’ve had to come up with complicated ways to get the original email text back out. We’ve reported this to them on multiple occasions and at one point had to actually put in a XSS exploit to get them to understand how big a problem it was. Over time they’ve shifted where the correct HTML will appear in the system, but never actually fixed it entirely.

So, coming back to the survey – what’s the point of interrupting users to get their feedback when you go and ignore it anyway?

Google Really Gets Enterprise Software

2009-07-30T13:16:07Z

I really don’t understand why companies don’t think Google has made their apps enterprise ready. I’ve been playing with the premium version of Google Apps the last few days and it shows all the important characteristics of enterprise software:

Innocent Looking Settings That Break Everything

Google has this in spades. My favorite is the fact that if you happen to disable a service such as e-mail, all the settings continue to apply, but disappear from the admin dashboard. The net result for me was that all the Google Apps suddenly failed to send any e-mail (but e-mail from every other source worked perfectly).

A Fully Integrated Service Where Nothing Works Together

Check! You’d think that the list of users in the domain would show through in applications like Chat or for sharing documents right? Nope, you have to manually type them in as if the domain users didn’t exist.

Overly Destructive User Management

Oh yes. Delete a user and all the documents they created disappear, regardless of how many other people happen to be sharing them at the time.

Ridiculous Limitations

Want to change the owner of a document? No problems, as long as they’re a member of the domain. Want to change the owner of a spreadsheet? Nope – can’t do that. Spreadsheets are special.

What’s Missing?

They managed to respond to a support case within 24 hours which is a major no-no for true enterprise software. It should take at least a week. To be fair, I made it very difficult by solving my own problem (the invisible settings I mentioned above) before they responded.

Hopefully now that Google has been enterprise ready they can start working towards actually making useful software for business…