They will have a lot of catchup to do to get where Office is now. I'm frankly amazed by how good Microsoft Flow has been.
So many dumb business processes rely on an Excel doc somewhere, or a stupid manual email somewhere else. But with Flow I've seen just a single smarty-pants able to fully streamline an entire department one rule at a time. They don't need to get permission to bring in a new logo - it's part of Office, they can just do it. And no one has to get dragged into it kicking and screaming - you want to work off of an Excel file? Fine! It's still there!
It feels like a hit of Agile steroids for an older organization.
Hahahaha. I stumbled upon Flow last year when I switched jobs. Our IT/procurement process is ridiculous, so I scrounged around our intranet resources for licenses and tools that I had access to by default or could get/request access to without triggering the Eye of Sauron to gaze down upon me from the tower of IT Security.
My team does analytics consulting work for large multi-agency marketing campaigns, and I used Flow and a shared mailbox to create sanity around managing the constant flood of daily/weekly/monthly data snapshots that get emailed and have to be synthesized and combined for end reporting/analysis.
I was also able to use Flow and PowerBI to duct tape together a "starter data lake" architecture for our marketing clients. It's been a wild success with clients, due in part because of it's price (in context to their expectations for traditional "data lake pitches") but even more so due to the fact that it gets rubber stamped through any IT review thanks to being all part of Microsoft. It fits most clients workflows and data volumes, and seamlessly transitions to a true data lake by pulling in Azure services as needs mature.
Most marketing departments are swimming in data but pretty lacking in their access to technical and process/operations resources to truly manage and leverage it. Flow has been a fantastic tool to introduce structured data management and automation for these clients, as it's low cost enough to slide under the radar, already implicitly allowed software as part of their Office 365 license, and gives them tangible results to show when asking for more budget to develop/mature it further. It's far from my favorite stack to use, but it's good enough to get the job done and breezes through all of the checks and objections and red tape that would make virtually any other stack dead on arrival.
/me is one of the minions from team "Eye of Sauron". However I'm not stuck in this tower.
I'm torn between two worlds. One side applauds the grass roots based solutions and the JFDI attitude. The other side is concerned that these solutions becomes widely used, de facto production, and problems upstream ends up breaking the output. On error, hopefully fails loudly but subtle problems could creep in. If the reports are consumed by other automation, the problem spreads rapidly.
Ideally the IT department would take a step back, assess what the users (you the stakeholder) needs are, and provide the solutions. Better Agile.
Using the successes to drive more development and operations budget is the way to go.
Until IT departments get infinite resources (that is, never) there will always be a need for these JFDI solutions. Some group will always go starved for attention and have to cobble together their own solutions. IT backlogs are always longer than the resources to do the work.
> Ideally the IT department would take a step back, assess what the users (you the stakeholder) needs are, and provide the solutions.
This approach was taken with Lotus Notes. The ivory tower decided who could create and control a database. All it does is throw up bureaucratic barriers people will work around. How much of your company is dependent on bespoke Excel databases? What better tools can you empower the employees with to mitigate that risk?
@cosmie provides a good model for IT organization to quickly bring supportable solutions. The principles behind Agile is to reach across these barriers / towers. These Experts are the product owners / users, the developers, and also includes UX designers, operations team, security team, and capacity team. This is ideal but realistically challenging to pull off.
A given Firm should also be providing a way for Shadow IT project to brought into the light, formally adopted and supported.
It's deeply flattering that you read to the end of my rambling comment, let alone referenced it! :)
I happened to be exposed to that model at one of my first professional jobs, and it was such an incredibly effective and seemingly obvious organizational structure that I presumed it was normal. Every job I've had since then has just deepened my appreciation for the brilliance and skill of whatever executive team pulled that off, as I've realized just how rare it is.
Fascinatingly enough, the organizational structure of that giant, traditional company bore a striking resemblance to how a software architect would approach designing a modern SOA on a cloud platform. And when the same principles of an SOA were applied to the design of the organization itself, the same communication structures, advantages, and trade offs emerged.
Which makes sense. Organizations and software are incredibly similar systems, and the parallels between the two allow for pretty seamless transfer of principles, best practices, pitfalls, mental frameworks, optimization opportunities, and reference architectures between organizational design and software design. Which is probably one of the hidden strengths of tech founders and the companies they create, since they'll implicitly infuse their experience at software design into the way they design all aspects of their company, even if they don't recognize they're doing it. Which is a competitive advantage over traditional business leaders that likely only have exposure to standard organizational design practices/teachings.
I completely understand the terrors of hidden dependencies on shadow IT. The work I do tends to grow up organically in different areas of every org, so I've hopped between functional business units, centralized business operations, and IT. When working for business units, I'm careful when I introduce technically advanced process dependencies. I either limit it to the level of technical competency that is generally accessible to the team or else I adopt whatever toolset the IT or development side of the house uses. That way there's always the potential for transition and I don't screw my manager/team over if I leave (or get stuck supporting it in perpetuity while I'm there).
This was an example of that. We do client consulting work, but we're only about 2% of the total revenue of our Fortune 500 parent and our IT policies are not conducive to client-driven work requirements. When my manager looked for what we could use when supporting analytics-oriented aspects of client work, tools like Supermetrics[1] were explicitly denied and IT provided virtually no automation/analytics solutions short of a complete Tableau server, which is prohibitively expensive for most of our clients' needs (especially when allocating IT infrastructure & support costs in addition to the license). I'm not a fan of the fragility and monotony of repetitive manual data collection and reporting, nor do clients like to pay for the excessive hours that takes on a recurring basis compared to competing bids (because presumably our competitors can use SaaS tools for automating rote process).
I scrounged around and found a pocket of PowerBI users in our IT's SQL Server team. Connected with the director over that team and got access for myself. Created a proof of concept architecture that provided an agile platform to address the full spectrum of our potential needs from "throw in basic analytics for free and eat the cost" to "maintain a full on data lake getting a deluge of real time data streams". Client users are guests invited to our tenant, log in with their (usually) already-existing Office 365/AzureAD user, can have the $10/user/month PowerBI Pro license added to their account via their corporate IT, our corporate IT, or a credit card expense. All of their ETL and data connectors and credentials and PowerBI models are compartmentalized into their own app workspace and subject to corporate DLP policies and accessible/auditable by Office admins. It's technically unsanctioned/shadow IT, but I ran it by the director of that team in case I needed to tap his team for sporadic support needs in the future, and he was both interested in my proposed usage and perfectly fine giving it his blessing (which is great, because his team manages the permissions I need for provisioning users, adding licenses, and creating workspaces).
The alternative would have been to either lose business due to non-competitive bids, use a combination of unsanctioned SaaS tools that get expensed and subject to disruption when turnover happens and passwords don't get shared or credit card renewals don't occur (fairly common scenario I've inherited), or using development skills to create custom automation that would be unmaintainable when I left.
> Ideally the IT department would take a step back, assess what the users (you the stakeholder) needs are, and provide the solutions. Better Agile.
This works well in some cases, but falls flat on it's face just as often. It's often prohibitively expensive from a budgetary standpoint for a business team to pull in resources for a needs analysis and subsequent project. Business users are far cheaper, so the vast majority of drift between needs and systems capabilities/processes go unresolved because it's cheaper to absorb the inefficiency on the business labor for quite a while before it hits a critical point that justifies the expense of pulling in ops/dev staff. For most business teams, shadow IT is a pragmatic stopgap solution to hit their deliverables, similar to the type of tech debt you see in IT projects that gets kicked down the road until it's suddenly not something that can be kicked anymore. And the process of IT stumbling across a grass roots solution acting as a de facto production dependency is basically a litmus test for when the debt finally comes due and triggers a formal needs analysis and IT project.
As well, that type of needs analysis generally creates localized optimizations or poor user adoption. The current needs will be a reflection of the processes that evolved within the current system and constraints, and addressing the directly will usually just result in a solution that's "a faster horse". Or it goes to the other extreme, where the solution you provide is state of the art and it turns out they have no ability to transition from riding their current horse to piloting the new fighter jet you provided.
A far more effective approach is to creative a collaborative model. Grass roots based solutions exist for a multitude of reasons and won't ever go away. But the concerns of undocumented, unknown, and potentially unmaintained de facto production dependencies existing outside of the purview of IT is a very real concern. So create a migration path. Put in low friction processes, support structures, and policies that give power users on the business side the ability to create sanctioned grass roots solutions. It'll allow business teams to experiment with and build up competencies and informed opinions on newer capabilities and possibilities, allowing for more nuanced and effective needs analysis for major projects. And it also provides enough oversight and management for IT to step in when usage patterns indicate something has become de facto production and warrants a more formal transition to/evaluation by technical and operations stakeholders. And also provides valuable data to ops/IT on where people are needing to create grass root solutions in general, which can better inform their own future systems planning.
Thank you! It has certainly been met with recognition, to the point where I'm essentially having to become a people manager again and create a team to support the capability across more clients.
>They don't need to get permission to bring in a new logo - it's part of Office, they can just do it. And no one has to get dragged into it kicking and screaming - you want to work off of an Excel file? Fine! It's still there!
Plus it wont be randomly cancelled when Google decides they got bored with it after several years of neglecting it first.
I've always wondered why Google is so bad at keeping various services going. Your comment caused me to reflect that Google hires a lot of smart people. Smart people tend to get bored with working on the same thing and want to work on new shiny things. Could it be that the smart people at Google do a bang up job of creating new services, but then get bored and move on to something new, leaving the previous service to slowly die and eventually get abandoned?
Google's promotion process biases very heavily towards "impact".
The problem is that maintaining existing projects generally isn't considered to be a demonstration of impact (or at least, it's a MUCH harder case to make). It's much easier to make the case that greenfield projects demonstrate impact.
Additionally, engineers have a good amount of power over what they get to work on: managers generally have to convince them to join a team. It's nice in concept, but lacks a steady influx of unwitting new engineers to help support all the not-so-sexy projects (like many other companies).
…so, you tend to see a pattern of engineers building a new thing, launching it, and then moving on to the next project. Leaving a trail of poorly supported projects in their wake.
Engineers lost a lot of their power from the Eric Schmidt days. It's the PMs that are fighting for controlling engineers now, and killing projects that the engineers are working on (thereby stopping engineers from getting the promotion they work for).
The promotion process is how you described though, PMs don't get promoted for maintaining projects, or even improvement on some metrics (that engineers are very good at), they always want new shiny stuff to brag about.
Can vouch. When you see an organization behaving a specific way, you can usually assume it's due to how they structure their employee incentives. Conversely, watch how the organization deploys its lymphocytes if you want to know what it considers harmful.
>I've always wondered why Google is so bad at keeping various services going
I'm starting to believe that it might be simply because low quality software is hard to maintain. They have some very complex software, but nothing of great quality. They might hire a lot of smart people, but not very many that are actually good at developing quality software. It appears that being smart doesn't make you diligent in your work, or give you an eye for detail.
Examples of this bad quality are simply everywhere; cursor left and right too fast in Google Image Search and that functionality breaks until you use the mouse to select the next image. Want to reply in Gmail, you have to click the reply button twice for the reply pane to appear. This is really basic stuff, and suggests a lack of competency in developing quality software, and a lack of care.
They are huge, but they are actually not very good.
> Want to reply in Gmail, you have to click the reply button twice for the reply pane to appear
This doesn't happen to me, and a quick Google (ha) isn't turning up complaint posts about it. This might just be a you thing.
Have you used Google maps? Or Google {search,photos}?
I get the feeling that they have two very different grades of software they write, and the stuff written by the varsity is so good that it's invisible to it's users.
I had to upgrade my two year old phone because GMaps was turning into a sluggish nightmare that wasn't usable on a non-retina display. Google has serious QC problems. Their varsity team still doesn't turn out best of class software.
Lack of care ? I don't think you understand what it takes to keep Search and Maps and YouTube working seamlessly. Many big systems that companies use were invented at Google. Sure you can find UI bugs or issues butt conveniently ignore that Gmail changed the game with it's 1GB accounts in the era of MBs. Or the uptime of critical services. You have no idea how important design and code reviews are inside.
> They might hire a lot of smart people, but not very many that are actually good at developing quality software.
This. They seem to hire people who are excellent Computer Scientists, but that DOESN'T make you an excellent software engineer!
The result is what we often see from Google: A product with an impressive/complex algorithm (whether it be AI or efficiency) wrapped in terrible software prone to tons of bugs and breakage.
To add to this, they can't even properly display screen saver photos on Chromecast from Google photos. My 4:3 photos get the top and bottom cut off instead of being letterboxed.
Properly displaying screen saver photos is the absolute least of the bugs affecting Chromecast. Ever try casting a 'watch later' queue of long-form YouTube videos from an iPhone? It loses audio sync constantly, drops frames excessively, loses connection to the chromecast device periodically, plays videos out of order; it's a complete disaster. I don't see how it ever left QA and went to market tbh. Google support exhausted all possibilities with me and left me with a "Sorry, nothing else we can do. #YOLO". They know it's busted, they don't care.
(a) watching movies letterboxed has yet to cause burn in on my OLED and (b) you could make the backdrop a frosted glass version of the same photo...
Not to say that every point is spot-on, but it’s true that Google in general makes their software and UIs complicated enough that outside of perhaps search or betas, they don’t update or change them all that frequently, maybe every two years at best. Apple or Microsoft could by now show them a thing or two on how to iterate user interfaces annually to evolve UI instead of making drastic changes folks might not like or sticking with the status quo forever with rollouts via obscure settings panels.
>Letterboxing causes burn-in on OLEDs, not exactly ideal for a screen saver.
They letterbox the portrait photos correctly. Well, sort of. They have a small gap between the top/bottom of the TV and the top/bottom of the photo. The letterbox area uses part of the photo so there's no additional risk of burn in. Even if they did just use black, I don't think black can be burned in.
Google's software is "free". If it was too good, it would kill competition. Google has one fear: to be cut in pieces because of monopolistic behaviour. Google, Gmail, Google map and google translate have almost killed concurrency. Google doc is improving.
I think it is more the Google reward system forces the smart people to work on something new. They pay out for crazy new things that become wildly successful and everything else becomes roadkill. Its like the employees are part of little startups and the executives are VCs.
It's because ads, google cloud, and a few other business units represent almost 100% of the revenue of Google (and parent company Alphabet).
In a deeply fundamental way, every service or software product that isn't part of the revenue stream doesn't really matter to the business and there is no incentive to maintain it.
Problem solvers are often (IMHO) also novelty seekers. Or looked at another way, who brags on their resume "I was hired by Google to be maintain the status quo!" Not many people want to be the Maytag Repairman. For those too young to understand the reference, Maytag's commercials suggested their appliances were so reliable that their repairman never had anything to do.
If the problem is really that Google doesn't hire any phone polishers and is hyper focused on new products, does it make sense for Google to spin off projects into somewhat independent subsidiaries? I have no idea if this is feasible within Google but it seems like breaking out some of Google's products into units with relaxed and/or focused hiring policies might help project cohesion. Seems like such a system could let Google keep its core campus type culture and also allow for better long haul support of certain projects.
Then again, if its just a matter of cutting any project that won't make billions, the point is moot.
The incentive system at Google for promotion (which is where the dollars get much bigger) rewards launches, not maintenance work. You'll see hundreds of people on new products that are launching and hardly any full time engineers, excluding SREs, on products that literally bring in a billion dollars because they just work.
I used to say that there were two kinds of people: people helpers and problem solvers.
People helpers are good tech support: "I'm sure I can help you. I've done this a thousand times."
Problem solvers are not: "I'm going out of my mind. I've done this a thousand times!"
It's more complicated than that, with people falling somewhere on an X-Y graph, some skewing one way and some the other.
Also, I used to think that all the values were positive. But there are those who not only don't help, they make the situation worse. And those who can't solve the problem, but make that worse, too.
What would be nice is if Google were to have someone who scored more on the "people helper" part. "Yes, this is older and boring but it's what people are used to and we're going to maintain it."
It seems like Google Documents has enough momentum that it's not going to just randomly get shot down. And it doesn't seem to be in the phase of getting neglected.
This is a cliche that gets wheeled out regularly but without much critical thought.
Google cancels stuff. A lot? Maybe but they have a lot of products.
But it's not without logic and it's much less likely to effect paid products and core services. How many parts of Docs/Drive have been cancelled? How many GCP components?
Next time someone is about to post another "Google cancels everything!" comment I hope they might pause and think whether it's plausible in this specific case. (And maybe pause to consider whether they are adding anything new to the debate or just repeating the same point that's been made a thousand times previously)
>This is a cliche that gets wheeled out regularly but without much critical thought.
Google cancels stuff. A lot? Maybe but they have a lot of products.
As a consumer of several of those products, I could not give less ducks what their problem is. That's an excuse for a Google PM to say to themselves.
Google's cancelling of products hurts me, and presumably others, and I wont trust it with business critical tasks when there's Amazon and Microsoft that have a much better developer record.
Google Inbox? I'm a paying user of corporate Gmail/GSuite and this is a pending disaster for me. They keep asserting that the "new improved" Gmail offers all the needed functionality but it simply does not.
1. A group of pinned emails in one place. I can star things, and they end up in "Primary". But if I then go to the "Promotions" or "Updates" folder and select all -> archive the starred items get picked up too.
2. Same complaint as above, but for "Important" emails. Except "Important" emails aren't moved into "Primary", they are ALL left in their regular boxes.
3. Does not have an endless scroll of emails. I need to click back and forth between pages to see them all. Select all only selects my current page of emails.
4. If I choose priority inbox I lose the ability to select all documents in a given inbox. The above are fixed with priority inbox, but then I can't select all. I switch back and forth once a week because I'm honestly not sure which features are more painful to live without.
If I could have a separate box for important/ starred and display ALL of my unarchived emails on the screen I'd be happy. Inbox taught me to make heavy use of archive and keeping an empty inbox except for what's essential... And then they provided no tools for continuing to use it this way.
The issue is that Google's interests are very often not aligned with their customers'/users' interests. They regularly choose to shut things down for reasons which probably make plenty of sense to Google, but which are unjustifiable from the users' perspectives.
Hangouts. But chat and the new video solution are a fairly seamless transition. So seemless that I've used the new video call solution for months and not noticed its name yet.
Microsoft Flow is a really powerful - in terms of advanced capabilities it offers.
If you're bought into the Office 365 ecosystem - the add-ins to Teams, Excel and SharePoint are really nifty. You can even run a "flow" over row data in Excel. I personally use this to file and track bugs - saves so much time for me.
It also has capabilities that allows you to connect to any REST API - look up Custom Connectors.
Finally, if you don't have Office 365, you can sign up for a free account using your personal Outlook / Microsoft account to test the waters.
Disclaimer: I work on Microsoft Flow and am very excited to see it here on YC.
Wait until you look at a general purpose cross-application robotic process automation tool.
The only reason they don't have more penetration into dev mindshare is because their tech stacks are generally in the dark ages (looking at you, BluePrism and Automation Anywhere!).
That said, I've been pretty happy with UiPath, both from an openness perspective and a technical one. They've got a free trial license to test drive it too, which is nice compared to the usual "Call us for a quote" sales BS.
If anyone wants to chat enterprise process automation, feel free to hit me on email. It's been my weird niche for the past few years. Username.co at gmail.
Wow, flow looks like a very powerful WYSIWYG based automator on their demo I just watched. Like they took the best of IFTTT and then baked it into business logic.
The comp I work for has half bought into the O365 thing. Most of us are on the semi-annual channel for desktop clients, a lucky few are on monthly no rhyme or reason.
And bec HQ is in EU they've decided to localize all web stuff to german. this makes entering dates or modifying formulas in excel online near impossible. Also for some reason they've chosen to keep flow and teams off by default, I can activate the free version of flow by going to it, but we don't get any of the powerBI integration we're already paying for. trying to explain the idiocy of this is like talking to 2000's era chatbot that can just assure it understands but doesn't really respond to any prompts.
> this makes entering dates or modifying formulas in excel online near impossible.
It would be so much easier, if the us finally stopped using this middle-endian date format. It's logically flawed and too prone for misinterpretation. Further the US is the only country in the world to insist on using it. yyyy-mm-dd or dd-mm-yyyy are both fine (I actually prefer the first, though my country uses the latter) and logically consistent.
While they are at it, they could also switch to the metric system.
the dates issue is actually a little more confusing than you'd think because when entering the date online you need to enter it as dd/mm/yyyy but it will display as mm.dd.yyyy (did you catch that, they change the separator too).
Re: formulas, they are all in german which means that unless I know the german equivalent word that microsoft chose, I can't make any modifications or even really write new formulas.
Actually Excel is smart here. It knows that Germany uses dots, but slashes are usually an indicator for the US. So you enter mm/dd/yyyy and it comes out as dd.mm.yyyy. (you see, you entered it flipped in your described experience). The easiest way for me is to enter it yyyy-mm-dd in a date formatted column and it will always catch the correct date.
I feel the pain with the function names. I know some in German and some in English, because I just switched to the native language at some point. But the translations are easily findable in the web [1] and there is even a built in function translator tool [2].
The reality of the German efficiency myth is actually just lots and lots of bureaucracy. something you'd never truly appreciate until you try living there (as a foreigner no less) for more than a few months... (my cousin explained it to me with what they call it. Papierkreig. Literally "Paper war")
Better than anything Google has to offer but I would heavily dispute that Flow is a quality product. Flows tend to randomly fail or don't trigger, log access is horrible and there is not really a mechanism for monitoring. Old classical Sharepoint (ugh!) workflows are more reliable, even if less flexible. (They are not really reliable, just better than Flow at this point).
Granted, Flow is still in development but I could not recommend it for production or anything of importance. They are few possibilities for backup (the browser based packaging doesn't count), nor any kind of functionality for advanced administration. I know Flow does also target non-developer audiences, but that is not an excuse to skip basic features.
I think being able to model workflows is essential for companies that do not want to spend large amounts of money on custom solutions. They can really remove a lot of busywork. The lack of real competition amazes me. Everyone would profit from a good workflow engine.
So Flow is only good, because alternatives are basically absent.
Serious question: What exactly is the advantage of Microsoft Flow compared to a scripted solution (using python or - to stay within the Microsoft ecosystem - PowerShell)?
What particular use-cases can it solve? E.g. is it easy to template Word/Excel document generation with it?
Is it just that you don't have to write any code to use Flow?
> Is it just that you don't have to write any code to use Flow?
"just"? that seems like a massive selling point to me. If the people that are supposed to use the tool in a company are not technical (or not technical enough) it doesn't matter how good the tool is, the first check is "does it need programming skills"
Office 365 is horrible for multi-user editing. When I last experienced it, we’ve lost edits, it’s that bad.
And actually I’ve lost edits with just plain synchronization on an iPad. I was on a plane, I edited a document I had, putting a lot of effort into it, then when my plane landed and the Internet came back, my changes vanished with no history recorded.
I've had similar problems with editing photos on an iPad using iPhoto and loosing all the edits when it tried syncing back up when I got connectivity again. I wonder if it's more of a quirk in the iPad APIs or something?
Yes, provided it’s stored in an MS cloud. In my experience it’s much more fragile than google docs. In my company trying to use it was a non-starter because there is too much friction to convince people to consistently keep files online and off of their desktop.
Is it still very desktop centric as all MS Office products? Because if it is you will struggle to keep up with the amount of data, report and automation that need to run on top of various cloud applications.
It's like IFTTT/Zapier/Huginn, but by Microsoft. It has all the advanced scriptability you'd need, but it's still missing some of the best parts of those solutions.
Definitely cloud-centric, and reaches into on-premises data through an optional on-premises data connection agent.
You'd be surprised at how much you can do with it.
(edit: especially powerful if you're using SharePoint)
Office is getting to (but not quite at) that sweet spot of "it just works". So long as you save into your Onedrive a lot of that is magically taken care of.
And then you get that one user who takes the collaborative document, downloads it to their desktop, then emails everyone a revision.
> And then you get that one user who takes the collaborative document, downloads it to their desktop, then emails everyone a revision.
This is a constant struggle for me. It took about 3 years, but I had most of our company using google docs and not working locally much. Then a critical mass of newcomers came and the IT department decided we should move away from google docs and so provided a file server. A year later, a few people of us are stubbornly using google docs but 80% of our files are scattered across the fileserver and desktops. And you can be sure that whatever you find on the fileserver is not the latest version.
While I’m on a rant, the same people refuse to use commenting features and instead add red text and text boxes all over the place.
I wished they would spend time on fixing bugs, Google docs has so many subtle bugs it is a very annoying product to use. Of course you could argue that you could do both new features and fix bugs but with budgets (even for Google) finite and new features not as critical as fixing existing issues I would love for the priority to be given to bug fixes.
Pet peeve: it is impossible to do a wysiwyg document in Google docs, it will come out subtly different on almost every computer/browser combo and in the end will come out different again when exported as a PDF resulting in endless cycles of revisions.
One class, or volcano, of bugs is sacredly kept only for the poor souls whos ancestors believed writing from right to left was the greatest idea ever (possibly after Monotheism). Try to write in multiple columns format in an RTL lang, then come back speaking of bugs. Then try a mixed RTL/LTR in a bulletin list. One would have thought bidi would be a solved issue in 2019, yet it consistently breaks every text editor ever made on earth.
I had to do exactly this for my ketubah for my wedding, can confirm it was a nightmare. Had never done RTL before, let alone both on one line. Took fully half an hour just to make 4 signature lines with labels
Then add a dollar to every microwave, washing machine, fridge, doorbell or other device with a hint of processing that uses a small embedded processor. Optimising transistor gate count for simplistic application is absolutely worth doing, even if you end up with an architecture that doesn't happen to be the same as expected by people who have only ever programmed for x86.
That's absolutely ridiculous. Don't tell me that if we really wanted to move 7 bit or whatever other wacky architectures to 8 bits, their price would go up by 1 dollar...
x86 is far from the only 1 byte = 8 bits architecture... PowerPC, SPARC, Itanium, ARM, MIPS, heck, I'm having a hard time remembering major non 8 bit-multiple architectures.
I was exaggerating a little for effect, but not dramatically so, once you take the multiplicative effect between BOM cost and price on the shelf.
To give you one example of a non-8 bit architecture, I used to work on CSR Bluetooth devices. For a while, the third most popular architecture was a little known thing called XAP, because it was in all of the 1-2 billion chips that CSR had made. XAP is a 16 bit processor in every way you can be a 16 bit processor: both the size of a byte (minimum addressable memory size) and the size of a word (size used for compilation) was 16 bit. You couldn't sub-address any larger types to serialise data. Also, the code space was separate from data space, and so function pointers were 24 bit (2 words). This meant that a lot of casting that developers take for granted wasn't possible (e.g. store a pointer in an int).
All of these choices meant that the XAP was very low gate count, and so very power and cost efficient for a surprisingly capable little processor.
The assumption that 'a byte is eight bits' is less specific than 'a character is one byte is eight bits' but I think captures it pretty well and affects at least all the people who are affected by RTL writing, I would think.
If anything, the one character -> eight bits problem was so large huge amounts of work has been put into developing and using libraries that abstract the representation of text away from byte streams.
"one byte is eight bits" is extraordinarily different from "one character is eight bits".
In fact, by conflating them you are implicitly making the assumption that one character is one byte, which is exactly what your comment is really warning against.
I agree with you, but was trying to illustrate an example from the class of 'one byte is eight bits' style assumptions.
Hopefully I made it clear that 'one character -> one byte -> eight bits' is an assumption that can cause a lot of pain. The simplest usage of non-standard character bytes I can think of from the top of my head is in SMS (as described in that interesting article that was submitted these last few weeks sometime) where the standard used 7-bit character bytes in order to get longer messages, and then struggled to deal with international character encodings.
Maybe it's drawing a long bow, but I think this specific example is of the same class of assumptions that jacquesm was describing when they said "a byte is 8 bits", and clearly this is a problem that will not "only cause trouble in rare cases".
Definitely agree on how annoying that is, but as far as I know no one has really pulled off client side rendering in any way looking even close to equal on all browsers and platforms. I know I spent years on another project trying to do just that before resigning to render the final result (PDF in this case) server side - so at least _that_ was consistent, albeit unfortunately not with the expectations one has from having seen the client side rendering before.
the entire productivity suite is very much an MVP product. the killer feature is real-time collaborative work, for that aspect it's actually quite good IMHO.
then for sheets, being able to work in "apps script" is fantastic. apparently you can use typescript in excel with some third party tools but surely they all stink in some way, and won't product portable documents. and anyway, VB is ok enough and has its own strengths.
otherwise, Office completely blows away google apps.
Another hugely annoying bug that I cannot get over is that it doesn't respect umlauts such as in German typed via US keyboard even when using the Apple way of doing it by holding the key and selecting. Maddening.
It must have been 2 years since I last tried Docs but at that time Japanese input was utterly broken. Both in Safari and Chrome (and in different ways in each browser)
It terrifies me how entrenched the Google suite is becoming, and more 'open' APIs will surely further that position. It's the default for most community / cross org collaboration and note-taking in my line of work. A huge amount of stuff gets done in Google docs.
And then Google ban your account for some random reason and you're suddenly barred from participating, your voice can no longer be heard, and who knows what happens to your existing contributions. I've not seen it happen first hand, but there are enough stories of people getting frozen out.
One alternative, which the Wikimedia community use, is Etherpad. It's ok for text editing but less polished.
People talk on HN about moral decisions about Google / Facebooke employees. Should that level of scrutiny apply to 3rd party plugin authors who help consolidate market share?
As the CTO for a company that uses GSUITE fairly heavily, the main reason I refrain from adopting Google tech isn't so much the risk of being banned, it is the likelihood that Google will simply abandon core integration points, and will force us to re-build whatever we've implemented in Google.
That too. But there's a difference between slow deprecation and being instantaneously cut off.
Every time there's a sob story that "Google killed my business by banning my Android app" there's a strong "your fault for relying on Google". But it seems like a blind spot when it comes to e.g. email and collaboration tools. Like Google's too big to fail.
While failure at a grand scale is probably unlikely at this point, I can totally see localised failure, such as a missed credit card payment or suspicious activity on an associated account causing absolute mayhem for an organisation.
A business running GSuite getting banned would indeed be a disaster, but has this ever happened?
For personal accounts, what happens if you create another account? It's also a big disruption, but "your voice can no longer be heard" seems exaggerated?
In a recent HN thread [0] someone's account was literally guilty by association with no recourse. That process is a black box. Maybe they could blacklist an IP range. Who knows.
Let's say we're note-gathering at a conference about metadata formats for international science collaboration. Often we get remote participants who want to join the conversation, and selection bias says that they especially come from developing countries and can't afford to travel. Those constituencies may have vital information which will help to guide a standardization process for shared metadata.
If they are blocked, for whatever reason, they may be unable to contribute to the conversation. Maybe their missing voice means that metadata systems add another piece of systematic bias against them and further excludes them.
I don't know of any specific examples where this has happened, but the underpinnings are all true.
The part I question is treating blocked/not blocked as a binary thing. There are often workarounds. Some are easier than others. Some people are more capable than others.
On the one hand we have people who need lots of hand-holding to use computers at all, and on the other hand there are very capable hackers for whom getting one account blocked by Google is a minor speed bump. Most of us fall somewhere in the middle in terms of resourcefulness.
There are many other barriers to getting online, including cost, connectivity, language, and cultural barriers. We're clearly not in a state of equal access. I doubt remaining in Google's good graces is all that big a contribution?
Yeah, at this point pragmatism meets principle. All of the above is true, but given a choice, why choose a platform where you even might have to 'work round it'?
Etherpad might look more scary, but it's designed specifically to promote inclusion and liberating data.
The thing that I find inspirational about the Wikimedia example is that they embody principles of inclusivity in their tech choices.
One cool thing I did with the Google Drive API was pull in our app's release notes from Google Drive. This allows our product and support teams to write/edit release notes and have it "magically" appear in-app as HTML. The workflow is:
1.) Employee creates a GDoc in a known, shared folder
2.) Application pulls all GDocs from this shared folder
3.) Application uses GDrive API to convert the GDoc to HTML
4.) HTML is displayed to the end user.
This proved to be an easy solution to having to involve a developer to fix a typo in a release note.
1- the API keys are only used on our servers and not the device, so no new worries about the key getting out and abused
2- we cache the results of the API calls for 5-10 minutes with Redis. So there's no worries about the quota or rate limits.
We've been doing this for about a year with 15,000 daily active users. When we publish a new release note roughly half read it within the first 24 hours. No issues to report.
thanks, but no thanks. I spent a month building integration with google hangouts, only to see it being deprecated before we could even launch. wasted months fighting with undocumented drive realtime API issues to make it work seamlessly and it was pulled last year without replacement. drive v3 api still does not have ETAG conditional uploads that drive v2 had. never biting that google bait and switch thing with apis again.
Google Cloud has a very different SLA and deprecation policy than the APIs for Google user-facing services. I have not seen a single feature deprecated or removed without replacement in Google Cloud during my usage over the last two years.
Great. Can we automate changing every single goddamn spreadsheet to not be in US date format? And while we're in there, how about adding a locale for New Zealand?
should set your locale across the board, rather than doing it on a per-sheet basis. If it doesn't work, as a Canadian, I empathize with your troubles and apologize.
Wow, that seems to have got closer, thank you. Spreadsheets are now created with Australian locale, although they have now lost their default timezone completely.
I'm interested whether this change will affect other Google products, in particular whether it messes up the operation of Google Assistant on my phone (possibly that can be overridden).
Oh cool. I've done a lot of similar projects in recent years with Apps Script [1]. With a script that's tied to a document (or even a standalone script that references Docs by ID), you can design your own API of sorts. Take in HTTP GET and PUT [2], run commands with DocumentApp [3], etc.
The upside to a system like that is, the authorization flow is abstracted completely out and handled by Google. You just pick from a dropdown as far as who you want to have access to the Web App URL, and you don't have to deal at all with setting up an OAuth flow.
I've been looking for a sophisticated way to automatically generate documents for a while (formulas, data tables) with the addition of one crucial feature that I haven't been able to find just yet: the ability to generate a document in addition to allow human editing. For example, this is my desired workflow, Step 1, create a document automatically, Step 2, allow humans to begin editing with tracked changes, and Step 3, potentially update the automatically generated content while keeping the edits. That workflow is what I'm looking for? Any recommendations?
That is actually an enterprise feature that gets very little recognition. There are many challenges with keeping it all in sync, especially if you have multiple contributors. But may I ask more specifics on your case? For me and my team is about getting forecats and kpis from humans into a central database from which we can then do further analysis and plotting, reports, etc
You can generate documents and other access other google api functionality with apps script https://developers.google.com/apps-script/guides/docs so you can not just create formulas, documents etc. but also emails, modify calendar events based on behaviors.
A logical feature, which I may even use. However -
Business-oriented releases like this need to come with a guarantee of existence for X years (some reasonable number) if Google expects anyone to use this for business purposes -- especially any paid/G-suite version (or whatever their premium version is called this week). Even then, it'd be a tough sell, as simply not shutting off the servers doesn't mean they'll actually actively update and support it.
Google, an advertising company, is competing against Microsoft, a software company with its roots in this exact type of software and thousand of companies with piles of MS-specific macros and scripts and processes they've been working with since the 90s.
Half-assing it is not going to work, even if they have a free tier available.
I use Google Drive regularly for personal documents, and even for my one-person business, but I wouldn't dream of entrenching myself in it in such a way that operations could be disrupted if they decide to switch the servers off next week with two days warning.
Search isn't going away. Maps isn't going away. But everything else Google is subject to a shut off at any second. Gmail isn't going away either, but your specific account could, with no recourse or appeal or access to your data.
The question we should all be asking at the release of ANY new Google feature shouldn't be "does Google have the engineering talent to make this good?". Of course they do. If Google wanted to start making space rockets tomorrow they could. The right question is "does Google have incentive in the form of advertising revenue to keep working on this?"
I predict this is another feature that has already been abandoned as of this writing, with no further updates to come.
Oh wow, this is pretty cool. I was actually planning to build a Google Docs plugin for my PDF templating product [1], and the UI was going to be very similar. They seem have a pretty simple API with limited types and field validation, so maybe there's still room for a more powerful competitor (that also has support for e-signatures.)
But it's really interesting to see how competitors evolve over time. Now HelloSign has been acquired by Dropbox, and Google Docs has launched their own document generation API.
They talk about Content Management, why not do some development on Google Sites finally. It seems like it's been idle for 10 years.
I would like to see some love for Google Sites so small businesses could use it make a proper looking website where content management would be over Google Docs.
I've done it on and off for about 15 years. I've done some in the real estate world as well. My experience in a nutshell:
* You have to use server-side automation - which is unsupported, and probably even violates Microsoft's terms of use.
* It's tricky. I use a serialized message queue to generate documents.
* Microsoft was dang stupid to not support automation. Such lost opportunity. I doubt that Google's supporting automation is going to change Microsoft.
Which parts are completely new that you couldn't do before? Haven't they had APIs for years that let you pull data out of documents and edit them as well? Or Google Docs specifically was lacking here?
That's cool. Know what else would be cool and probably get more use? Fixing bugs, improving performance on large documents, and bringing the feature set more up to date.
Our use case is replacing placeholders inside documents with generated values, removing or adding entire sections, and exporting to pdf. Looks like that is all possible.
This is interesting and kind of weird at the same time. I think Google has missed the point completely with this. While it is true that the future of documents is API driven and task automation will meet document editors, this is simply not the way forward.
It's like Henry Ford giving people who are looking for faster and more economical transportation an assembly line instead of a car. Here is why:
- Task automation, by definition is supposed to save time and money. By building a developer API, you still need developers (whose time costs more money!) to build and maintain your automations.
- The underlying document model itself cannot be accessed. So what they've made is some kind of HandleBarJS way of creating documents and filling them in.
I'm working on something in a similar space (https://afterclass.co) and we've had to build our own document model and automation handler to work around these two problems. Would be interesting to see how this pans out :)
I was pretty psyched about this, but it looks like you can't control table styles with it? Styled tables are a pretty big part of how you end up controlling formatting in GDocs, so I don't think I can build this into our workflow without that.
I’m glad to see that binding data with document templates is slowly becoming used more often. I always saw it as a killer feature, and actually built one of my products around that idea way in 2011 [1].
Once you leave the simple use cases of just replacing tags it gets quite complicated, but you can build really complex documents that way [2].
Google is ridiculous with its API restrictions and lackluster offerings. For a software company it astounds me how poor and mismanaged their API options are. Unreliable in the sense they pull the plug a lot with these pet projects leaving devs hanging. Can they be trusted?
Genuine question, What's the use case for this? If you already have to do some programming how is it different from generating html documents (like invoices) (that can be converted to PDF) and some web forms for filling out the templates?
One use case is generating contracts. The end users can maintain and author the contract templates because they are in a familiar environment. Then use the API to plug data into the placeholders to create the finished doc.
It seems all of this was possible before the new API.
Google Docs already had an HTML import/export API, which allowed you to download a document, make changes, and save those changes back again. That would allow you to implement any kind of templating you like. This API just makes it slightly easier and more visible.
> This API just makes it slightly easier and more visible.
Yeah that's what APIs do. You can usually work with CURL requests/scraping too, but it always feels clunky and improvised, much like the method you are describing seems to me.
Making something easier means making it more accessible, means the tech based around these tools will advance faster, and that's good for everyone. It's not just a new bauble, well, except it's Google, but it will be very useful until they inevitably abandon it.
That is a salary below the minimum wage in many major American cities and only 200% of the federal poverty line. I'm not suggesting six figures, but maybe 40,000? It just seems odd to me to use a figure that low in a example.
It holds more weight than your baseless accusations, but please refrain from posting inflammatory comments that do nothing to further the conversation.
You may want to read those links you posted, since this story does not fall into those well-defined categories. Telling people their statements hold no weight based on false accusations is definitely inflammatory. Me simply pointing that out is certainly not inflammatory. If you follow the HN rules of etiquette, then we can have a productive conversation. If not, then good day to you.
Google Docs has approximately 1 billion daily active users.
Hacker News has fewer than 1 million monthly active users.
Google is a deeply polarizing HN topic, where many of any article's comments reduce to snark about longevity of Google products, or proclamations that anyone using Google services is a fool who doesn't understand privacy.
Please tell us more about your theory of Google's astroturf marketing campaign on Hacker News.
I can’t speak to workflow longevity. My assumption, based on enterprise work experience, is that corporations using Office 365 and MS Flow are going to prefer that workflow over Google Docs (and they’re probably already federated to Azure AD, making access control easy peasy).
People want to derisk what they deliver, and want to keep their jobs. Microsoft delivers on that, Google does not. This isn’t about emotion, it’s about pragmatism.
No doubt there are enduring legacy effects of enterprise Office use. There's a very long tail there.
However, I think Google is approaching this from the End User standpoint. They're making it possible for people with just a little tech skill to start making magical things, no engineer required. The paradigm is shifting as we speak.
FYI the Python quickstart.py is broken on Ubuntu 18.04 (tried both python2 and python3). I've notified the eng in the video, and sent her here.
By definition, credentials.json doesn't exist yet and this throws an error. Transcript below.
creds = None
if os.path.exists('token.pickle'):
...
# If there are no (valid) credentials available, let the user log in.
if not creds or not creds.valid:
if creds and creds.expired and creds.refresh_token:
...
else:
flow = InstalledAppFlow.from_client_secrets_file(
'credentials.json', SCOPES)
creds = flow.run_local_server()
$ sudo apt install python3-pip
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
grub-pc-bin libpython-all-dev libpython-dev libpython2.7 libpython2.7-dev python-all python-all-dev python-asn1crypto python-cffi-backend python-crcmod python-crypto python-cryptography
python-dbus python-dev python-enum34 python-gi python-idna python-ipaddress python-keyring python-keyrings.alt python-secretstorage python-six python-wheel python-xdg python2.7-dev
Use 'sudo apt autoremove' to remove them.
The following NEW packages will be installed:
python3-pip
0 upgraded, 1 newly installed, 0 to remove and 11 not upgraded.
Need to get 114 kB of archives.
After this operation, 599 kB of additional disk space will be used.
Get:1 http://us-east4-c.gce.clouds.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 python3-pip all 9.0.1-2.3~ubuntu1 [114 kB]
Fetched 114 kB in 1s (175 kB/s)
Selecting previously unselected package python3-pip.
(Reading database ... 128010 files and directories currently installed.)
Preparing to unpack .../python3-pip_9.0.1-2.3~ubuntu1_all.deb ...
Unpacking python3-pip (9.0.1-2.3~ubuntu1) ...
Setting up python3-pip (9.0.1-2.3~ubuntu1) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
$ python quickstart.py
InstalledAppFlow.from_client_secrets_file()...
Traceback (most recent call last):
File "quickstart.py", line 47, in <module>
main()
File "quickstart.py", line 32, in main
'credentials.json', SCOPES)
File "/home/asah/.local/lib/python2.7/site-packages/google_auth_oauthlib/flow.py", line 171, in from_client_secrets_file
with open(client_secrets_file, 'r') as json_file:
IOError: [Errno 2] No such file or directory: 'credentials.json'
$ cat quickstart.py
from __future__ import print_function
import pickle
import os.path
from googleapiclient.discovery import build
from google_auth_oauthlib.flow import InstalledAppFlow
from google.auth.transport.requests import Request
# The ID of a sample document.
DOCUMENT_ID = '195j9eDD3ccgjQRttHhJPymLJUCOUjs-jmwTrekvdjFE'
def main():
"""Shows basic usage of the Docs API.
Prints the title of a sample document.
"""
creds = None
# The file token.pickle stores the user's access and refresh tokens, and is
# created automatically when the authorization flow completes for the first
# time.
if os.path.exists('token.pickle'):
with open('token.pickle', 'rb') as token:
creds = pickle.load(token)
# If there are no (valid) credentials available, let the user log in.
if not creds or not creds.valid:
if creds and creds.expired and creds.refresh_token:
creds.refresh(Request())
else:
print("InstalledAppFlow.from_client_secrets_file()...")
flow = InstalledAppFlow.from_client_secrets_file(
'credentials.json', SCOPES)
creds = flow.run_local_server()
# Save the credentials for the next run
with open('token.pickle', 'wb') as token:
pickle.dump(creds, token)
service = build('docs', 'v1', credentials=creds)
# Retrieve the documents contents from the Docs service.
document = service.documents().get(documentId=DOCUMENT_ID).execute()
print('The title of the document is: {}'.format(document.get('title')))
So many dumb business processes rely on an Excel doc somewhere, or a stupid manual email somewhere else. But with Flow I've seen just a single smarty-pants able to fully streamline an entire department one rule at a time. They don't need to get permission to bring in a new logo - it's part of Office, they can just do it. And no one has to get dragged into it kicking and screaming - you want to work off of an Excel file? Fine! It's still there!
It feels like a hit of Agile steroids for an older organization.