Hacker News new | comments | show | ask | jobs | submit login
The world needs a better spreadsheet (voyager.vc)
179 points by mmonihan on Jan 20, 2017 | hide | past | web | favorite | 92 comments



Eons ago, I worked for Lotus Software (way before they belonged to IBM) on an exiting new product - their flagship Lotus 1-2-3 spreadsheet product, in those days the preeminent spreadsheet offering in the world, ported to the IBM mainframe.

I travelled around Europe as we sold this to large corporations who wanted the power of the spreadsheet, but multipled by a gazillion times and made multi-user.

Almost every customer was so receptive and excited, it was a fun and job and easy sell.

But later, we learnt that those customers were in fact the early adopters, and Lotus never did manage to cross the chasm with that product. Later Microsoft produced Excel and..well the rest is history.

My conclusion: the world doesn't need a better spreadsheet. Existing spreadsheet technologies are good enough for the hokey, half-baked things that people like to build with them.


I like that you're bringing up Lotus, but I was thinking of a different product: Notes.

It's from another digital software age and from experience, hard not to think of the applications created with it as archaic monstrosities, yet there was something there.

In many ways it was what the OP is talking about: a networked formbuilder that allowed for people with technical skills roughly equivalent to that of an Excel superstar to build actual line of business apps.

For those same reasons, it had lots of issues. Often a spreadsheet is the right choice, maybe not when it gets to be 200MB and corrupts itself because multiple people are accessing the same file across the network.

Notes apps worked until they didn't, but are still kind of fascinating in their awfulness.


Apps like Lotus and Access get a bad rap that is unjustly deserved. People did a lot of amazing things with those applications.

The presence of zombie Notes apps that spew out of control is more a statement about IT than the platform. My mom, not a power user, was a public health nurse. She put together with a sophomore intern what grew into a good sized disease outbreak tracker after IT failed to deliver. All in Notes.

The IT idiots discovered it and got all puffy. They siphoned off funding and stuck its "enterprise" replacement into some portfolio process. 5 years later and $5-6M spent they launched a replacement that didn't quite do what it needed to do. She retired almost 10 years ago, and that little app still lives for a few use cases.


I used Notes as recently as 2010 at a mega Corp. Another friend was using it in 2013 at a professional services firm.

Those apps were simultaneously powerful and broken. The sheer number of apps the company had was staggering. "There's an (notes) app for that", only 20 years prior.


There was something there. What you say is definitely true. When I made Notes apps though, there was always some scripting involved in terms of LotusScript for the Notes client, or Javascript for the browser. There was a Java API as well in the late 90s that some people were using instead of LotusScript. It was a bit more powerful, obviously.

Of course, some people just used the @ formulas.

Anyway, I haven't come across anything that so naturally expressed document workflow with forms and email integration. People complain about Notes email, but it was nice to have it so tightly integrated with the Notes capabilities.


Spreadsheets changes lives like mine. Especially 123. The second most .exe used on the pc, behind doom

123 put extreme power in the hands of skilled users. If you mastered print code strings it provided for many promotions and tech opportunities. Even today the spreadsheet is the Letherman or slide rule of old time geeks.

I still have a 123 startup disk for my compaq ( no hard disk. 2 floppy version. )

123 changed many people's lives. Truly.


I thing that good spreadsheet application with seamless integration with web and with collaboration tooling would be interesting. Decent scripting with something Julia and some kind of build in Jupyter notebook would be exciting to use. Integrated version control where each document lives in own repo that you can shared as just link shpreadsheet:://user.myNewspreadsheet

Excel is relict of old ages: slow, bug ridden, impractical. In my job whenever I need to work with excel I feel pure hate. I send hundreds of this shit to people that are non technical and they... they... send it back.


I think of spreadsheets as like q-tips. Apparently the one thing that the manufacturers of q-tips tell you not to do is to stick them in your orifices. Yet the number one actual use of q-tips is people cleaning gunk from their ears.

People build the most insane, unmaintainable, insecure messes using spreadsheets - because they can.


But they can also build a lot of really useful things too, and many do, and create a ton of value.

The same can be said for any programming language/tool. Reminds me of this quote attributed to Doug Gwyn:

"Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things."


And you can FAST. What else is there for quick and dirty stuff????


iPython or Jupyter Notebooks, where you can whip up R, Julia, or other code in your browser, interspersed with markdown, charts and formulas.


Emacs


I like to use org-tables for my spreadsheets:-D

I'm joking... mostly. That said, I really have used elisp functions on an org-tbl in anger before.


There is also ses-mode (Simple Emacs Spreadsheet) that started shipping with Emacs since version 22.


Collaboration is great, but it should start with files. I want to be able to save things to a directory and send them via email. And have a stand alone format that can be archived. File based work flows are used for good reasons.


As I very vaguely recall the initial iteration(s) of the Windows version of Lotus 1-2-3 weren't great. The real killer though was probably Microsoft's bundling into Microsoft Office. That cemented the use of the entire suite of Microsoft products even when, at a given point in time, they may not have been best in category.

As I recall, Lotus made some purchases to try to follow the same strategy but it was too late by then.

There were also the attempts at fully integrated products like Symphony and Framework (Ashton Tate) but the loose coupling really won the mass market.


Lotus went straight to OS/2, because Windows was a toy. Oops.

Around 1991 they had an all-new cross-platform super-product under development, but it crashed and burned and they had to plough on with 123.

I did a lot of the low-level GUI coding for the Open Look and Motif versions of 123. Fun times.


Would that be Lotus Improv? I used Improv and Quantrix on NeXTStep. Quantrix on OSX is still a secret weapon of mine.


I don't think so. They all had code-names - 123 for Windows was Rockport; Improv was Back Bay and the one I'm talking about was another place, but the exact name escapes me.

I believe Improv was written in Objective-C while the one I mean was in C++.


C++ is impressive for 1991. Excel was still K&R C at that time.


Did you also get to work on Lotus Improv? What are your thoughts on that in comparison to traditional spreadsheets?


I used Improv and Quantrix on NeXTStep. Absolutely loved it. I still use Quantrix on OSX to this day.


Nope, I don't recall anything whatsoever about Improv. Lotus Notes was the new goodness a little later on.


I remind Jobs saying 'even half done your thing is so revolutionary you owe the people to sell' or close.

Improv is way above the pack... so much it's not a good thing.


Perhaps, In the end, the best piece of software is the one you never had to build in the first place. -- The Article

Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble? -- SICP

I think the real uncanny valley here lies in maintaining software, not designing it. Business needs change over time and software must adapt.

I think the best option is to build your own software. Understand it top to bottom and make it do exactly what you need to do. Sadly this is not possible for most people.

The next best option, however, is not to spend $3,000 on something written over a weekend that won't be supported down the road. The best option is to go with the Salesforce solution.

My first programming gig (in high school) was automating a process that involved manipulating index cards and doing some basic math. I also trained them on how to operate, maintain and extend the system. The end result worked fine for a few years, until it was eventually replaced with some elaborate proprietary system that cost about as much every 3 months as the whole system I delivered. But that system came with ongoing support that obviated the need for any in-house expertise. So they felt the additional expense was worthwhile. And I was happy not to have to take the support calls.

Edit: And ultimately both systems were more accurate and saved time over the manual process.


OP. This is a great point. The activation cost for you to respond to support calls is probably more than the company would be willing to pay you. Which is why SaaS businesses with support teams that benefit from scale are the de facto model for these businesses.

I think there's a version of something like Microsoft Access that can take away a lot of support requests.

I get a ton of requests related to lists of collections within the app, which could be maintained by the users themselves.


> I think there's a version of something like Microsoft Access that can take away a lot of support requests.

Yes, and it's called Salesforce (or Dynamics if you like more pain than Salesforce already causes).

I have better things to do than write a full front-to-back webapp to organize garbage scattered around in spreadsheets, so it's been a lifesaver since I can create a new object or field in a couple clicks (and if I need to write some custom UI or backend code I still have the option to do so).


> Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to always see it as a soap bubble? -- SICP

That was written what, 40 years ago? Fast forward today now computer hardware is meant to be discarded! protocols change, batteries and disks are sealed inside cases, driver software is abandoned to cloud-disabled... a piece of hardware 3 years old is ancient, unsupported, trash.


I have been reading HN for more than 3 years. It is like an addiction. I have never felt smart enough to comment something but honestly, this is the worst piece of literature I have ever read.

The writer is just rambling on irrelevant stuff while trying to be smart and promote himself and his company.

It's not even good marketing.


Agreed. I'm not sure exactly what I read, but I couldn't piece together a single coherent line of thought as we jumped from sketchy individual developers to requirements gathering, something about UX, valleys, zombies, Salesforce as a CRM (except it can do anything really 'cause it's a platform), to the closing statement about perhaps not building the application you thought you needed. And what did it all have to do with spreadsheets, or building a better one?


Agreed this article is lacking a real thread.

Re spreadsheets, I am one of those dreaded 'advanced Excel' people and some of the comments i hear about spreadsheet limitations are a bit like saying 'this chisel is a rubbish hammer'. Our main use is to take small amounts of data from our ERP and browse/sum/subtotal it in some way for adhoc analysis or sharing, or keep the record of some minor detail over time. I have seen thousands of lower skilled users use spreadsheets in this way and there is no better tool. Indeed accountants often run much more complex stuff, but tend to be very dilligent with their inputs and versioning and have little trouble. As soon as you have concurrent users a spreadsheet becomes a bad database substitute.


> this is the worst piece of literature I have ever read.

The first line says it is a transcript from a talk, so you shouldn't expect literature.


OP. Thank you. I spit out my soda laughing reading this.


Nailed it. I started out surprised he would charge 3k for making some cheap lotus notes crud thing he wrote in 4 hours and couldnot deploy in heroku in 8? Then there was this free associating on a bunch of unrelated concepts topped off with some kind of general axiom.

Nice work getting 3k for that kind of project, you're a better business man than me. If someone like that came my way I would direct them to Google forms or spreadsheet for free.


I'm seeing a lot of hate for spreadsheets here.

First, to state the obvious: in the time your least-favourite Excel sheet took to grow from simple time-saver to sprawling Cthuloid monster, it has probably saved multiple person-years of effort. You could spend the next six months rebuilding it all "properly", and it's still comically positive ROI.

Spreadsheets are also a unique, top-level category in computing as a whole. By my count, there have only ever been three schemes of interaction with computers (with any significant adoption):

1. Shrink-wrap. Use the software you've been given. Read the manual; that's what it does, no more.

2. Programming language. It's text, it's got syntax, it's got the same basic constructs as any other programming language. You know they're all the same, because once you know a few languages, you can start using a new one in an hour or two.

3. Spreadsheets. Visual interaction, scaling smoothly from "simple calculator" to "this is the backbone of our whole business".

Spreadsheets really are that fundamental a discovery in the field of computing. Give them some love.


Aside: This is also why the OP's wishes for "a better spreadsheet" so often run into trouble. If you take a spreadsheet and naively "add more power" with a programming language, you're producing an abrupt transition from mode #3 to mode #2. This spooks the user almost as much as learning to code from scratch - and for the same reasons.

I don't have an answer for this. For https://anvil.works we deliberately avoided this pitfall by never pretending to be a spreadsheet (or, for that matter, shrinkwrap, like Salesforce does). We make you write code from step 1, and get comfy with it, because if you started in any other paradigm it would be too hard to switch. And if you don't write code, you'll never get much advantage over just using Access.


But why not word processors or presentation software (PowerPoint)? How about Photoshop? That's pretty big.

Edit: oh, you're not computing something so much as you're using shrink wrapped software to build documents, presentations, or manipulate images. So, not quite the same.

As for programming languages, I disagree. You don't go from only knowing say Python, PHP and Java to being able to use Haskell in a few hours. There's a substantial learning curve in being able to use a sufficiently different programming language. And no, "Hello, World" or typing in a few simple commands from a tutorial don't count.

Do you suppose the a C programmer is just going to be building a meaningful Smalltalk or Lisp program after a couple of hours? Or that a Javascript programmer is going to be whipping up C++ applications in that amount of time?


I've seen orgs run on Excel spreadsheets: one electric utility I worked for described their load in one massive Excel sheet. Where I think this analogy falls apart is that so many spreadsheets come to depend on macros (which my experience did, via ODBC), which makes them a meld between 2 and 3. I've definitely written systems at level 2 -- at the same company -- that have had way more ROI than the spreadsheet based system that was previously employed, but the spreadsheet could have employed macros to do the same thing.


Spreadsheets are the poor man's data processing pipeline; they ship with a wealth of numeric and data munging functions and give you an easy-to-understand visual representation of your datastore. You can use them to crunch numbers and graph, but also to implement fairly complex business logic, and they accomplish this within the confines of an application you probably have already bought anyway. They're the epitome of the entrepreneurial spirit you need to survive adversity in the SMB space.

Spreadsheets don't succeed outside of pure numerical calculations because they're that good, they succeed because they're versatile and ubiquitous, and everyone already has Excel or Google Sheets. If everyone already had, say, Sharepoint, or even some drag-and-drop no-cost rapid application generator that requires zero sysadmin skills to run, that would be the new baseline.


I agree. The problem is also that most people who are running SMB aren't experts at growing their data model. Over time, the owner needs new objects (rows, columns, sheets, etc.) and new things that need calculated and tracked BUT they also need to associate these new things to the old things. They are not going to be able to renormalize the data model (they don't know they have). They make new sheets or Excel files and do the best they can. It is flexible and can do whatever they want but that doesn't make it more efficient. I don't think that most of these people need new or custom software. They need someone to come in once a year and help them re-optimize their processes against the new reality. Excel might be enough but there has to be an investment in making that an efficient tool.


Sounds like someone should come in and turn that into a database that feeds excel.


I agree with this in premise, and had a very similar idea with a friend earlier this year - that many of the business apps out there are really just CRUD apps.

The main piece of feedback that we got when pitching this idea was that you're going to end up as a master-of-none. Yes, we could give you the tools to set up Customer, Ticket, etc. objects. But in order to win over Zendesk, you're going to need all of the features they provide. Chat, ticket queues, automation, etc. Business users also don't want to be architects - a turnkey solution that solves 80% of their use case is better than a blank slate that they have to start thinking about schemas, relationships, etc. The old saying "nobody ever got fired choosing IBM" can now just as easily be applied to VP of Sales picking Salesforce.

That being said, there ARE tools to do this: Quickbase (enterprise) and Airtable come to mind. I'm curious if the author has looked into using one as their base instead of Google Forms/Sheets.


OP. This is an idea I've been going back and forth on for a while.

I have checked out Quickbase, Airtable, Ragic, etc.

What I've noticed is that I always want the ability to go to code when I need to. My clients are all on Rails apps today, and I'm happy with rails as a dev solution. And, I don't want to give up that flexibility.

However, there are use cases where I want to just use a form builder UI to manage a data model. I've been using http://form.io for that recently. You use a form builder to generate a UI and an API simultaneously and submissions are stored in Mongo. And, I can build the app as I want using their API.

I think that paradigm is the future, it just needs more refinement.


Ah alright - so definitely more aimed at people who can code. Ours was more focused at end-users.

That is one area where Salesforce shines. APEX and Visualforce can get you just about anything you may need for customizations. I'm sure something similar will pop up, but then people will complain about having to sell your soul to them, too :)

Workato is another nice tool to augment Quickbase & Airtable. It's like Zapier, but allows you to add some code (Ruby in fact) to do custom hooks.

I guess it really depends on how complex you need to go, which then brings me to my point about being master-of-none - at that point you're losing your abstraction and essentially building a custom app.


Salesforce is a great solution for stupid CRUD apps that require some custom code here or there. A year ago I started with 8 users, now I'm at 40 and counting - I don't have to waste time developing a front-to-back web application to keep track of garbage that was stored in spreadsheets, and my users get rapid turnaround on most changes (hey, add this new object or field please!).

And if your users don't need to access a lot of different "types" of data (objects) the $25/mo "App Cloud" license is a cheap way to get going.


Zapier has custom Code steps (Javascript & Python):

https://zapier.com/help/code/

https://zapier.com/help/code-python/


For quick CRUD apps, where a spreadsheet is your admin panel I recommend Sheetsu.com (I'm founder). You get REST API, from your spreadsheet. What you do with it is up to you.

We see a huge peak with agencies and freelancers using our service, just to avoid building admin panels for a client. Easy, clean & simple.


I posted upthread already, but I would really love to know what you think of Anvil (https://anvil.works).

We're aiming squarely at your use case: more than just a form builder; less fuss than fighting Heroku for four hours.


The long tail, though, is huge here. Anything that actually expresses your business workflow is going to be more specialised, and people end up really chafing under one-size-fits-all solutions (as evidenced by the bottomless demand for custom line of business development).

Our big point with Anvil (https://anvil.works) is something already noted here: The key is being able to write real code.

Pure Crud - anything sufficiently simple to do with a spreadsheet - is going to be done by a slick single-purpose startup. But anything that requires custom logic, you won't get quite what you want and you'll be stuck in spreadsheet-land or spending thousands on a contractor. Offering people a choice between those extremes can relieve a lot of pain.


> The main piece of feedback that we got when pitching this idea was that you're going to end up as a master-of-none

Interesting. I'm working on a product based on a similar premise, for end-users, but focused on financial services.

I'm curious, did you try pitching to customers, or just investors?


We were still having product-market-fit surveys with potential customers, and friends (some of whom are investors).

I think narrowing down to a specific industry like you're doing helps the problem immensely. A true schema builder is a hard sell to both non-technical users (when point solutions offer more with WAY less setup) and technical users (see how tech people view Salesforce, for example). However, Quickbase and Airtable are doing it currently. Very interested to see how Airtable matures.


"The world needs a better spreadsheet"

I read this when I was a teen (as that's long ago). It was at a time Lotus was going to launch Improv in 1993! Improv was the attempt made by a very smart team at Lotus to reconquer the crowd that went to Excel.

But as you can guess, the great product never found its market (or never grew beyond a niche) and was killed a few years later.

cf. https://en.wikipedia.org/wiki/Lotus_Improv


It's worth noting that Quantrix Modeler [1] (founded in 2002) did carry on the torch after Lotus Improv, and continues to exist. That said, it's not clear how much traction Quantrix got either. It was bought out in 2010 by IDBS and te deal value wasn't disclosed, but it was reported that they had only nine employees at the time of acquisition. Another very interesting earlier attempt in this market was Javelin [2].

[1] https://www.quantrix.com/ [2] https://en.wikipedia.org/wiki/Javelin_Software


While I'm not entirely sure if "the world needs a better spreadsheet" is a stand in for "accessible prototyping tools" it's worth noting that things like Quantrix Modeler and DADiSP are the better spreadsheets it's just that no one uses them because Excel (and by extension Excel work-alikes) have path dependency on their side.


And those products are thousands of dollars a year while Excel comes bundled with every mass market computer.


Yeah, fair enough, that too.

I happen to think "paying for good tools" is a good thing but as a student/stockboy: A thousand dollars is a fucking lot of dollars, especially if your business is still running on debt.


Fundamentally software development is about writing and managing complex systems. Excel and the like have limited capability to manage complexity and any simple system built with excel eventually turns to bad smelling unmaintainable chaos. So then people build tools that manage complexity better but are still "easy to use". And then those tools become so complex that software developers are the only people who understand how to use them. And then what's the difference between said tool and writing real code? After 10-20 years we are back to where we started. I wonder exactly how many times I will see this in my career?


Not really. Most spreadsheets(~88%) have errors.

"Sorry, Your Spreadsheet Has Errors (Almost 90% Do)"

https://www.salesforce.com/blog/2014/09/how-to-reduce-spread...

The 2008 source article is

"What We Know About Spreadsheet Errors"

http://panko.shidler.hawaii.edu/SSR/Mypapers/whatknow.htm


If you read the blog, you'd see that the system he's suggesting is somewhat more robust than a spreadsheet. His example at the end is the Google Forms builder, which at least does a modicum of input validation, unlike your typical direct-entry spreadsheet.

And the point is not to completely dismiss the idea with a glib soundbite like that, but to actually take seriously building tools like spreadsheets that allow non-technical users to build data-driven systems.


I built an app in Excel 5 years ago. It was a heat map for events, for stadiums, theaters, etc. I would build the static CSS/HTML and write out the files from Excel. It is still in use today. After having stopped working on it for a couple of years a minor bug was brought up to me recently. Luckily I had a windows computer again with Excel installed. Excel is a great platform for building prototype apps, or even long lived apps - especially 10 years ago. It is amazing the power that Excel has. But, a proper app should be built in JavaScript with a solid back end (F# being my fave). Although developing in Excel was a bit clunky it was amazingly easy to get beautiful customer interfaces and beautiful forms.


It exists already. It's called MS Access.


Except Access has many of the same issues as Excel. You can work around some of the nastier stuff like file locking by using liked database files and having everyone save their own copy of the "frontend" database file, but it's more of a pain in the ass than it's worth (and oh god is it slooow).


I think you mean MS SQL Server, it is faster and has more features than Access.

Access is good to prototype a database and use GUI/UX controls to make forms and other stuff. It is good for small projects, but once you need to upscale you need to go to SQL Server. I did this in the late 1990s and early 2000s migrated databases from Excel and Access to SQL Server.

On Linux, people use MySQL or PostgreSQL for the same reason and upgrade from SQLlite3 etc.


<shudder> how many paths to mdb corruption? Let me count the ways.

I wrote Access apps in college for cash to doctors and small business and I still have no love for the tool.


I agree, I automate generation of hundreds of spreadsheets a day.

I would like to see more scripting/automation features on email.


OP. I was actually thinking something similar. Do you mean the ability to send out emails with app data rather than code and orchestrate them yourself?


I was thinking more on the processing of incoming emails, ones with attachments or routing. I worked years ago on an enterprise product that did this, but it was integrated with large printer.


What data was being sent back and forth? Why did you need to process the attachments?


Quip (a better spreadsheet) or Django web framework (its ORM and built-in admin can do wonders) are worth mentioning. Another example that comes to mind is how Vox uses Google Sheets for content & config: https://product.voxmedia.com/2014/7/29/5863004/take-a-peek-a...


Being part of design meetings, it's amazing how many endless customizations and workflow adjustments people like project managers and consultants like to request for a new piece of software. But when it comes down to it, most users don't want a complex, hard to understand interface that has so many features it's supposed to improve everyone's productivity. Most people want to use their spreadsheet, their Outlook calendar and their IE browser. Not because it's best at the task, but because that's what they know and are used to.


Of course users don't want anything complex, and if the resulting custom software makes a task more confusing and error-prone than a spreadsheet, the developers and designers have failed.

Instead, I read this comment as meaning a few different things:

1. It is difficult to get users to try something different.

2. Most users don't comprehend the limitations of the software with which they are already familiar.


> most users don't wan ... so many features

mmm. which features do you want?

and you over there, which features to do you want.

and you, in the corner?

It adds up, doesn't it!


Once you get all the security, backups, data validation and whatever exporting/search capability the people need a system like this is never simple. I wonder how happy they really were with his software vs relieved to have a semi-functioning system.

It still seems like something like this is in the realm of possible. Salesforce mostly does this, but its UI is garbage and most people end up hiring implementors for it.


Quickbase does an amazing job with allowing non-tech users to create their own crud apps, and the model is very spreadsheet like, including grid edit if you want.

The trouble is the pricing model. $25/user per month for the edition that's not hobbled. For some use cases, that makes sense. For others, it's just way too high.


Airtable is a better spreadsheet imho.


+1 on Airtable, it's the only app I have used in the past 5 years that fits great into workflows and allows me to peer into and sort the data based on the task / view I need.


What's with that garbage at the bottom right? I'm trying to read your article. Why would I want to talk to you before reading your article? Made me stop reading.


Charged a close friend $3,000 for a few days worth of work?


$100 x 8 x 3 = $2400, and that's for just 8 hours a day with a pretty gentle contracting rate.


$100 per hour for a Rails crud app?

For a close friend?


Close friend lowballed you on three days of work?


I make more than enough money from my day job, such that I don't need to nickle and dime my close friends.


how do people get a "hey HN" welcome line up on their site so quickly? This was posted here less than 2 hours ago. Do people really monitor incoming referrals hourly?


I mean...yes? Back when I had a dedicated office, there was a screen that was tail -f on various logfiles watching website traffic.

My sites were all personal projects, so the traffic was low enough that I could notice an uptick in traffic visually.

Also things like google analytics etc.


It was posted by the creator, that makes it quite easy ;)


I think most folks do it automatically, e.g.

    Hey { referer }, ...
I was surprised the text was still there in incognito mode.


There must be an app to notify you of HN/Reddit/Tweets that mention your domain?


I swear to god, anytime anything pops up on a website when I click on it, it seriously pisses me off.

A fucking chatbox? I already hate your company.

A fucking chatbox from the author of a blog? I hate you and everything you stand for. You are what's wrong with the internet. You should know better, and you do. But you do this anyway. Just stop.


OP. Yea, that was interesting on my end using chat. I probably would hate that on your end as much you did. I did have some pretty fun conversations though. I removed it, because that got exhausting.


I, for one, really liked it. And thanks for the chat, Matt!


I stopped reading when the chatbox obscured the screen also. I'm confused on what the author is trying to achieve.


apparently the spreadsheet the world needs is really a chat app.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: