Created with React and Material-UI, plus some spreadsheet fetching and parsing code.
Glad to answer any questions!
Are you using Node.js? Would love some feedback on my lib since it seems we are doing the same thing for different user types!
That said, I wish I had stumbled upon your library when I first started out. It looks better designed than the one I initially used (which I promptly abandoned because it couldn't handle certain errors properly, and I decided to roll my own).
What names did you use to try to find it if you don't mind me asking?
I wrote an article about how to set up a platform like those mentioned + with write functionality (https://blog.usejournal.com/how-to-use-google-sheets-as-a-cm...) but I've always wondered if there would really be a market for such a thing. There clearly is anyway for read-only Google Sheet generated sites.
Your article is pretty well written! More people should look to using sheets before hand-rolling a heavy weight solution.
My niche happens to be to quickly create a single visually pleasing web page from a sheet.
"..you have to pay £5,400 per year!"
"Even with the nonprofit pricing it would cost $900 per year."
"Pricing for singe user with one "app" is $60 per month. The "free" version only allows 100 "views" per month. Everytime you go to the page with the app and interface with the tools it counts as a "view". Everytime you refresh the page it is another "view"."
Have you run across this? How did you solve it? Thanks!
But that being said I'm not sure this is static HTML either. You're going to need someway to parse and display that sheet data. Even if its server rendered as static HTML React isn't a bad way to go.
Imagine a SaaS that sells domains, then provides and easy (and open) API for delegating control over subdomains using OAuth2.
So I sign up for sheetui, and during the registration process they redirect me to a namecheap.com (where anderspitman.net is registered) OAuth2 server, I grant them control over sheetui.anderspitman.net, and they can now host there on my behalf.
sheetui.com also shouldn't have to deal with TLS certs. Why doesn't namecheap.com handle that for me?
HTTP requests can be proxied through something like ngrok which again uses OAuth2 tokens for auth. Now we have a stack where people can securely host websites from there phone.
What issues did you run into with OAuth2? Are you open to sharing your design doc?
One of my goals was that the flow could start from a service provider - you type in the domain name you want the service to be bound to on the service provider's website, and it goes from there. If you were to use OAuth2 at this point, there's no existing client ID/password, and allowing public dynamic client registration leads to DoS potential as someone could easily register a practically infinite amount of clients and fill up disk space. So you want a custom flow which winds up, at the end, with the consent of the domain owner, returning OAuth2 credentials to the service provider. This flow is fairly complex to spec out in a way that doesn't have subtle security issues (e.g. this initial flow can't trust much info from the service provider which could be something akin to a phishing scam, returning to the service provider on error has to be done carefully because of risk of being used in an open redirect chain, etc).
After that it's mostly a case of supplying auth keys for RFC2136 so the service can manage its delegated domain, handling credential rotation, and properly handling edge cases like either the service provider or the domain management system losing track of state, or the domain being lost/transferred to another entity.
Honestly I'd like to build something like this for my own projects, and might do so as a weekend project soon, esp since it's just been validated as something useful. :D
I'm not a big fan of pre-registered clients in the first place. Ideally any client should be able to talk to any OAuth2 server that speaks the same profile, ie endpoints and scopes. Aaron Parecki describes a way to allow "anonymous" clients here. As I understand that's how IndieAuth is implemented. But I'm still relatively new to OAuth, and I don't doubt there could be subtle security issues. Do you have any thoughts on that?
For example I'm working on a project right now that's ideal for self-hosting, but I really want to encourage people to use their own domain names, and registering them and handling HTTPS is a rather large barrier.
I'm guessing you guys use Liquid based on the curly braces? It looks like you have a pretty nice UI for manipulating the dynamic data, but if you're interested, my product helps people write Liquid: https://www.dropkiq.com/
Let me know if you're interested. Otherwise, best of luck with your product!
For Dropkiq, your app looks simple enough (for the Liquid part) that you could likely use our free version. For apps that have complex Liquid, we have our Pro version, which I'm currently offering beta pricing at around 1K per year.
Keep us in mind as you grow! :D
A lot of folks don't realize Google Sheets is like a free small database with a decent API. :)
I like that SheetUI has the things above built-in and more functionalities like adding buttons and a customisation UI.
Is a custom-CSS feature going to be available anytime soon? It would be great to be able to add some original styling to a website.
Thanks for showing me Liftoff! The generated websites look great. I'll see what I can learn from it.
Thank you for considering this!
I would like to know if you are going to add more features later. For example, informal 'About us' pages would have links to social media in their bios. So can we have more than primary and secondary buttons?
Also, it would be lovely to have profile photo frame customizable. It looks stylish to have the photo embedded in a circular frame for example.
Circular frame coming soon!
Our team at Sheet.Best (https://sheet.best) was just talking about reducing the entry barrier for our services and one of the ideas was something like this.
Nice to see more competition on the "no code" approach to use spreadsheets as databases :).
I kind of like some of the Brutalism takes on web design. Just throw away all decoration and live with the ugly world, “ugly” being subjective. I think excel sheets are actually quite beautiful.
Challenge the status quo :-) at the expense of coolness, dignity and comfort.
Part of conveying information should be about making the information easy to digest. Sometimes a spreadsheet fits that bill. Other times a crafted UI works better.
Excel sheets are essentially rectangular grid with borders. Grids have been used since the 60's in graphic design, primarily championed by the Swiss Grid System (Josef-muller brockmann, et. al).
So if you say that excel sheets are not a good instrument to convey information, you're saying that a grid like structure is not good at laying out information in a logical, understandable fashion. Which is provably false - everything from Tax forms to road signs, every bit of graphic design professionally conducted uses the grid system.
Think a bit deeper than just aesthetics and ask yourself, what exactly is an excel sheet? It is a bunch of boxes. Whether those are div elements or excel cells, what's the difference? Padding and margins?
One idea I have is to go back to the simpler days of MSDOS GUI. We can generate such a UI using some custom markdown, and for the most part it does simple CRUD, with plugin support for complicated stuff. The focus will be on speed (keyboard navigable with Windows alt+<letter> shortcuts), and brutalist UI in the form of MSDOS GUI.
I'll fix this in the next iteration by providing defaults.
Considering how many people across so many industries use Google Sheets as part of their processes, I'm convinced there is some money to be made.
I want the reverse of this service - I just want the raw data from any web page in a spreadsheet ready to filter and sort and define new columns as I please...
It's somewhat of a shame that HTML never quite managed to split data from representation. It managed to separate content and styling, but the content is still treated as some kind of text document, not a textual representation of some data.
Example usecase:. eBay search results, I want to sort by "Price plus $0.50 per mile from me", since I'm going to have to drive my van to pick up the item.
That would be super easy with a spreadsheet of the search results, and I could probably have the data sorted in under 60 seconds on a column of "=B5+C5*0.5"
I can see another variation of this being useful as well. Instead of loading live data all the time, it loads the data at time of publishing and creates a static html page with an option to auto-publish to github pages or netlify or something like that.
Turn your Google Sheets into a beautiful Gopherhole :)
A much closer transformation.
I would like to see what it looks like.
Product Catalog: https://sheetui.com/view/grid/image-tile/1F92PXwyE5CTjkT-Sin...
Team roster: https://sheetui.com/view/responsive-grid/media-card-2/1F92PX...
Yes? Google is notorious for deprecating and changing things, so I would have a backup plan but companies like Streak have built large businesses on much more restricted APIs like Gmail.
> kind of loophole
This is not a loophole, this is 2-legged Oauth. This is much safer than the typical 3-legged Oauth where the user gives blanket permission to read and write from their Google Drive. The user has to explicitly share the sheet with this service account email. Google is trying to protect people from clicking a phishing link and getting all their email and drive content stolen or hijacked.
Yes, Google can shut this down tomorrow or demand thousands of dollars to use it. It's a inherent risk building on top of someone's platform, the trade off being you get the scaffolding and user base the platform already has.
> Drive - Any Drive API scope that permits an application to read, modify, or manage the content or metadata of a user’s Drive files, without the user individually granting file-by-file access.
I could be wrong, but to me this suggests you can use the Sheets API against a user-specified document without it. It has it's own namespace of scopes that's not under drive.X
(might want to rethink naming)