Here's an icon that could be used for Brix documents: it shows some Lego bricks. "Lego consists of colorful interlocking plastic bricks and an accompanying array of gears, minifigures and various other parts. Lego bricks can be assembled and connected in many ways, to construct such objects as vehicles, buildings, and even working robots," informs Wikipedia. Maybe Brix is just a collaborative web application based on SketchUp.
There are also icons for Fusion Table documents and Google Sites, which could be included in Google Docs:
Brix could be the foundation for document assembly functionality. Like as in a Brix document contains a standard bit of company boilerplate with variables somehow flagged as such. You would need to be able to call out Brix documents and set variables in your master document so that when you hit "print" you get all the pieces in the right place.
ReplyDeleteI have no particular reason to think Google is getting in to document assembly, just that it seems really easy and would be a handy functionality for a lot of enterprises.
I'm guessing it's a new way to build websites using Google Docs made public.
ReplyDeleteOr it's just this...
ReplyDeletehttp://code.google.com/p/brix-cms/
So I am guesting what tom is saying is that Google docs is built on Brix or is going to be at some point in the future?
ReplyDeleteTom's link shows BRIX mas moved to GitHub. This may indicate the name interfered with Google's intention to use the same name.
ReplyDeleteJust to coin a wild idea: it may be that BRIX is the new name for GAS (Google Apps Script) a name that maybe was found to be a bit to burpy-farty.
It may also indicate developers may find their scripts stored as special documents in Google Docs. Such a feature has been missing from GAS and this omission would make it much harder than necessary for developers to find back scripts
ahab good point I missed the name change.
ReplyDeleteIs this good?
ReplyDeleteIt could be a concept on the lines on EVERNOTE - any thoughts?
ReplyDelete@anonymous
ReplyDeleteSo, in other words, Google Notebook?
if you compare to googles android app inventor, the brick idea might be some scripting with predefined "bricks" just as in the app inventor environment.
ReplyDeleteso i guess ahab might be pretty close.
maybe you can soon drag&drop those brix to create own scripts for google docs.
I am betting it's a macro language AND an interface to build macros and programs that use Google Apps. This is similar to what Visual Basic was for MS Office, and is exactly what Google Apps script is trying to be now.
ReplyDelete"Brix" is probably going to be the new brand name of "GAS" and come with a new, simpler development environment for building Brix which may work like Automator for MacOS X. This IDE will likely be integrated with the existing "Google Apps Marketplace" so you can buy/use other "Brix" in all google apps.
its Google notebook
ReplyDeleteQuesto è molto simile a quello che Visual Basic era per MS Office, ed è esattamente quello che sta cercando di essere adesso Google Apps script. By Pricescout24.it
ReplyDeleteI think ahab might be barking in the right neighbourhood, though I'd consider that Brix is either:
ReplyDelete1. Google's Cloud "parallel" to WSC.
2. Google's Cloud "equivalent" to OLE.
ad.1: Just by seeing the Brix name and icon, I couldn't help myself saying COMponent (as in Microsoft COM, DCOM, COM+).
When ahab said: "It may also indicate developers may find their scripts stored as special documents in Google Docs."
Then - Yeah, but I think (and hope) that it'll be more than just simple script files, being ready-to-use by a simple include-statement (declaration) in another script or socket. I smell a Google Cloud variation/analogy of WSC (Windows Script Components).
(I realise that WSC's are little know to most people, so I found one short description here: http://blogs.msdn.com/b/ericlippert/archive/2003/10/08/53180.aspx )
It may be that J. McNair is correct in Brix becoming a commodity via ex. Google Apps Marketplace, though I seriously think it's a bit premature(or immature) for that to happen (GDocs's track record for releasing full featured defect-free new things, does not call for entering any market involving hard cash).
ad.2: Let's face it, Copy & Paste between different GDocs document types (whether using the WebClipboard or not) - does sometimes lead to imperfect formatting. And Copy & Paste functionality is most certainly no match for Object Linking & Embedding. (introducing "OLE" in GDocs also seem to fit a timeline saying that Google's Office Cloud world is 15 years behind MS Office in its history of making). One thing that Google has been doing for a long time, is making Gadgets (ex. iGadgets for iGoogle, or embedding "anything" by WebElements, or ...); So hand on heart: It's about bloody time that data ("fragments"/Objects) found within same Google suite (GDocs) could be integrated & exchanged (aggregated) with each other, by more than simple Copy & Paste.
Cool app
ReplyDeleteAnd we're still waiting for GAS (Google Apps Scripting) being introduced into GDocs Documents.
ReplyDeleteOn Feb.7'th 2011, Google was aiming at March (my calendar is now approaching May)
Ref. http://code.google.com/p/google-apps-script-issues/issues/detail?id=25#c7