Printable View
Has anyone seen the Word 2010 xml interface fully exposed? Is there a resource anywhere which documents/shows this? It's one thing to have the excel spreadsheet listing all the controls... it's another thing to see the xml in action (and adjust it by using a start from scratch mode).
Or, in a simpler version... Here is a recreation of the Font Group on the Home Tab... except for the separators, which don't seem to be allowed within boxes.
A bit of a neophyte in the xml structure... anyone have any hints? Did Microsoft promise something which isn't actually true (i.e., they would expose all the components of what makes their interface "go"?)
Just to clarify: how can I make my new font group look exactly like the Microsoft font group (I'm currently missing the necessary separators, but they aren't allowed child elements of the boxes, and boxes seem to be required to get the two "rows" of buttons centered vertically)
Note: I have cross posted this in the Word forum here.Code:<ribbon>
<tabs>
<tab idMso="TabHome">
<group idMso="GroupFont" visible="true"></group>
<group id="grpFontCustom" label="Font (new)" imageMso="WordArtFormatDialog" insertBeforeMso="GroupFont" autoScale="false" centerVertically="true" >
<box id="bxFont1" boxStyle="horizontal">
<control idMso="Font" visible="true"/>
<control idMso="FontSize" visible="true"/>
<control idMso="FontSizeIncreaseWord" visible="true"/>
<control idMso="FontSizeDecreaseWord" visible="true"/>
<gallery idMso="ChangeCaseGallery" visible="true" />
<control idMso="ClearFormatting" visible="true"/>
</box>
<box id="bxFont2" boxStyle="horizontal">
<control idMso="Bold" visible="true"/>
<control idMso="Italic" visible="true"/>
<gallery idMso="UnderlineGallery" visible="true"/>
<control idMso="Strikethrough" visible="true"/>
<control idMso="Subscript" visible="true"/>
<control idMso="Superscript" visible="true"/>
<gallery idMso="TextEffectsGallery" visible="true"/>
<gallery idMso="TextHighlightColorPicker" visible="true"/>
<gallery idMso="FontColorPicker" visible="true"/>
</box>
<dialogBoxLauncher>
<button idMso="FontDialog" visible="true"/>
</dialogBoxLauncher>
</group>
</tab>
</tabs>
</ribbon>
http://www.vbaexpress.com/forum/showthread.php?t=38524
Not sure about how exposed you want to be, but I found this helpful (at least for 2007). Have not seen much about 2010 yet
http://msdn.microsoft.com/en-us/library/bb190933.aspx
http://msdn.microsoft.com/en-us/libr...ffice.12).aspx
http://msdn.microsoft.com/en-us/libr...ffice.12).aspx
http://msdn.microsoft.com/en-us/libr...ffice.12).aspx
Anything specfic?
Paul
Thanks for the links, Paul. I've actually read that fascinating 3 part series (and have the printouts with coffee stains to prove it!). :)
Specifically:
I'd love to have the XML for the entire Word 2010 ribbon, if that was floating out there somewhere. It's so much easier to modify than it is to recreate (I know there's an interface for modifying the 2010 interface, but exporting it, removing the mso:/idQ stuff and importing it into a global addin or a COM addin is a bit of a hassle)
Very specifically:
In recreating the font group (as an example, xml code above), I can get close, but as Greg Maxey has pointed out, two things are different in my version vs. the one natively provided by Word.
1. Word native is two rows, centered vertically, however, there is more space between those two rows than my two rows.
2. I'm unable to insert separators, since they are not valid child elements of the horizontal boxes necessary to get the other look (centered vertically, "line-breaking" where I want them to).
Very very specifically:
I just want to, for this exercise, remove the Text Effects menu button from the native font group. But you can't remove specific elements of a native group.
Any ideas would be welcome. Greg pointed out something I had just discovered... that a label element with "|" as the label would serve.. but it looks clunky and not like the native separator.
Just a quick update, as I'm continuing to play around with the various options... this is actually a bit closer (having changed a number of the generic types "control" to their actual type allowed me to see a few additional options... to make the Font combo box the same width as built-in one)... but I'm still left with the same issues:
1. Spacing between my two rows is less
2. I am unable to insert separator where I want
3. The space between the font and font size combo boxes is larger than the built-in.
buttonGroup seemed promising, except that comboBoxes aren't allowed inside them. I've also tried putting separators outside of the disallowed objects (box), but telling the separator to be inserted before or after a control which is in the box. It doesn't generate an error, and it does send a separator where I want... but it basically split the box as well, so the effect is destroyed. I'm left with seeing if a custom image is the answer, although that won't solve #1 or #3.
I'm continuing to try various strategies... and if I do figure out some neat trick the Microsoft designers did utilizing the same tools, I'll post it. But it seems like they cheated.
Code:<group id="grpFontCustom" label="Font (new)" visible="true" imageMso="FontColorPicker" insertBeforeMso="GroupFont" autoScale="true" centerVertically="true" >
<box id="bxFont1" boxStyle="horizontal">
<comboBox idMso="Font" visible="true" sizeString="Times New Rom" />
<comboBox idMso="FontSize" visible="true"/>
<button idMso="FontSizeIncreaseWord" visible="true"/>
<button idMso="FontSizeDecreaseWord" visible="true"/>
<gallery idMso="ChangeCaseGallery" visible="true" />
<gallery idMso="ChangeCaseGallery" visible="true" />
<button idMso="ClearFormatting" visible="true"/>
</box>
<box id="bxFont2" boxStyle="horizontal">
<toggleButton idMso="Bold" visible="true"/>
<toggleButton idMso="Italic" visible="true"/>
<gallery idMso="UnderlineGallery" visible="true" />
<toggleButton idMso="Strikethrough" visible="true"/>
<toggleButton idMso="Subscript" visible="true"/>
<toggleButton idMso="Superscript" visible="true" />
<gallery idMso="TextEffectsGallery" visible="true" />
<gallery idMso="TextHighlightColorPicker" visible="true"/>
<gallery idMso="FontColorPicker" visible="true"/>
</box>
<dialogBoxLauncher>
<button idMso="FontDialog" visible="true"/>
</dialogBoxLauncher>
</group>
Quote:
But it seems like they cheated.
I wonder if they used something like a COM addin to make the standard interface??
Paul
Well, I was building this in Visual Studio 2010 using a COM addin (which is how I learned what options were available and what options weren't-- developing the XML in VS 2010 is more like the VBA IDE where pertinent options pop up, rather than the freeware Custom UI Editor I was using before).
I think, if you stick with the 2010 xml schema, you're stuck with separators not being allowed in boxes... which suggests to me that they developed their ribbon in something similar to, but not exactly, the xml schema they opened up and made available to us.
In any event, I appreciate the reply. I did post this (today) on the MSDN forums, but it seems as if the same people respond there as you see elsewhere (Cindy Meister, etc-- knowledgeable people, but not the developers). And I haven't known MS developers since 1999, so I have no inside scoop anymore.
It just seems a bit mystifying... why come up with this open source concept, and then not use it to develop your own interface. They clearly had some kind of structure. Why not expose it? That's the frustration talking. I think, ultimately, this is an unanswerable question.
Update: The only other piece (which isn't really worth posting) is to try and use a custom image on a disabled control for a custom "separator"... the labelControl seems to be the best "out of the box" solution, both for separators and for the occasional horizontal spacing. Here is the XML for that, for anyone interested.
Code:<group id="grpFontCustom" label="Font (new)" visible="true" imageMso="FontColorPicker" insertBeforeMso="GroupFont" autoScale="true" centerVertically="true" >
<box id="bxFont1" boxStyle="horizontal">
<comboBox idMso="Font" visible="true" sizeString="Times New Rom" />
<comboBox idMso="FontSize" visible="true"/>
<button idMso="FontSizeIncreaseWord" visible="true"/>
<button idMso="FontSizeDecreaseWord" visible="true"/>
<labelControl id="lblSep1" label="| " enabled="false"/>
<gallery idMso="ChangeCaseGallery" visible="true" />
<labelControl id="lblSep2" label="| " enabled="false"/>
<button idMso="ClearFormatting" visible="true"/>
</box>
<box id="bxFont2" boxStyle="horizontal">
<toggleButton idMso="Bold" visible="true"/>
<toggleButton idMso="Italic" visible="true"/>
<gallery idMso="UnderlineGallery" visible="true" />
<toggleButton idMso="Strikethrough" visible="true"/>
<toggleButton idMso="Subscript" visible="true"/>
<toggleButton idMso="Superscript" visible="true" />
<labelControl id="lblSep3" label="| " enabled="false"/>
<gallery idMso="TextEffectsGallery" visible="true" />
<labelControl id="lblSep4" label=" " enabled="false"/>
<gallery idMso="TextHighlightColorPicker" visible="true"/>
<labelControl id="lblSep5" label=" " enabled="false"/>
<gallery idMso="FontColorPicker" visible="true"/>
</box>
<dialogBoxLauncher>
<button idMso="FontDialog" visible="true"/>
</dialogBoxLauncher>
</group>
Couple extra notes: be careful trusting Microsoft. Some of the above "controls" need to be left as "control" types, rather than the specific type ("gallery").
The Underline button is a great example... it's technically a splitButton, but it is named UnderlineGallery. If you leave it as a gallery type, it removes the splitbutton functionality. If you name it a splitButton, you'll get a User Interface error. However, that's the name of the button (easiest way to find out the name of the buttons, if you can't find them in the excel spreadsheets, is to add to the QAT and export the customizations... then go through and find the name of the control).
However, microsoft always exports them as "controls" instead of the actual type... and changing to the appropriate type in Visual Studio helps during design to see what options are available in the schema for a particular control.
Where did MS promise that ... they would expose all the components of what makes their interface "go"?
AFAIAA, they said they would expose the ribbon, and it is easier and more extensive using VSTO rather than just changing the XML, but they never promised us it all. As an example, we couldn't squeeze a group in 2007 as built-in groups could, and much more.
I have just come to accept that MS will never give us full control over the ribbon, they would rather have given us none but couldn't get away with that, they do not see it as a programmable component, more a presentation component.
Fair point. I supposed they didn't promise anything. However, they have made attempts with each version to a) make the UI development more stable (Office 2007) and then b) more accessible (Office 2010).
Anyone who did heavy development work with the commandbars object model in versions of office prior to 2007 understands why they threw the whole thing out and started over with the xml-based Fluent UI.
And I assume they are utilizing some kind of similar schema to what they exposed, except that they turn off certain "features" they have access to because of memory issues (i.e., they have the opportunity to optimize trouble-some bits of UI code within the winword kernel that may cause some things to come to a grinding halt if they allowed the entire world to develop in the same parameters).
It just seems kind of a big miss to disallow some of the functions illustrated in this very simple exercise (re-creating the font group in Word 2010).
In particular, the work-around for being able to have .BeginGroup = True on *any* control rather than just controls not within a sub-structure seems particularly egregious.
And I respectfully disagree that they don't see the ribbon as a programmable component. I think they are always edging towards exposing more... but with the limitation that they need to make sure Word is stable first, and modifiable second.
I just can't believe that allowing separators within boxes is something they disallowed in the "save them from themselves" bailiwick. I think that's a simple mistake.
If I understood XML schema better, I suspect I could somehow tell my XML code *not* to check in with the /office/2009/07/customui schema, and it would probably work... I'm just not quite sure yet how to do that.
Disagree 100% there. I did a ton of development work with commandbars, and they were easy, even VBA commandbars. The (ef)fluent UI was not introduced to be more stable, it was done under the auspices of 'discover-ability', which it has palpably failed to achieve in my view. In reality, it was introduced to give a new look-and-feel to try and push people into wanting, and buying, the new release, i.e. all about sales.Quote:
Originally Posted by Frosty
Then why do we still have commandbars for right-click and so on?Quote:
Originally Posted by Frosty
If this were true, why haven't they allowed us to dock the ribbon on the left, right or bottom rather than just the top. We have asked for that since day 1, as well as tear-off groups, because monitors are getting wider so taking up vertical space is not desirable. But MS have ignored this (in favour of more visual bling!).
I don't see that would be possible, the schema is different for each release, so it would seem to be wired-in to me.Quote:
Originally Posted by Frosty
Well, everyone has different experiences. I found commandbars to be extremely buggy and unreliable in Word 2000 and 2003, especially when dealing with all of the different addins which get integrated with Word in a corporate environment. Yes, they were simple in concept, and tended to follow a fairly simply set of rules... but there was also a fundamental problem with the commandbars collection which would rear its ugly head in a variety of ways. Of course, I had a best practices and would tend to avoid the various bugs... but I wouldn't ever call commandbars "stable" when I could click on one commandbar and at times see the contents of another.
I'm certainly no Microsoft apologist, but nor am I a Microsoft hater. I don't think everything they do is purely for profit and as a way to screw over the end-users. I think they were trying to go for something more slick (of course) as well as an easier to understand interface for the average user. Those of us that understood all the old rules obviously find this change frustrating. But from an objective perspective, while I prefer Office 2003 because I understand it better, I *think* Office 2010 is probably the better product for the average user. Of course, give me time. With familiarity breeds contempt, and I'm still learning this version (I basically skipped Office 2007).
Of course, I'm not the average user-- so a lot of what you seem to be frustrated about also frustrates me :)
I can think of logical answers to some of your questions, and don't have some for others. Most of it simply has to do with the amount of time spent in development and needing to get a release out. They always have unfinished (but mostly stable) concepts they put out in a release: i.e., taskpanes in 2003 (unfinished, but didn't cause Word to crash).
I'm not quite sure how you'd dock the ribbon on the left and the right without some pretty significant impact to the ribbon code. The bottom-- sure, although you're still going to have the issue with where the longer menus need to be displayed. For the record, I absolutely agree that the ribbon is too tall, and that the UI designers should be investigating the use of the right/left areas of the screen. My guess, however, is that they ran out of time in 2007 to allow the Ribbon to appear in more than one place on the screen, and then they ran out of time dealing with all of the other problems in 2007 to address it in 2010 (File menu/Office button, anyone?).
As for the most on-point part of this thread ;)...
Yes, the schema may be hard-wired in, but I'm pretty sure you can develop a COM addin using a different schema (and, perhaps, even your own?). I'm just learning this part of office development, though... my expertise has been within the actual application moreso than the development of 3rd party apps for use with the application. It seems as though I could potentially get the schema used by MS, make adjustments, and then write a custom UI using that adjusted schema, at least from the various bits I've cobbled together in my research. But honestly, despite having been an Office VBA programmer for 15+ years, I only recently wrote my first COM addin. Just sort of the way my career went.
Oh, and just for the sake of philosophical discussion: besides my experience of commandbars being buggy, there may very well have been some fairly core parts of the commandbars code which just didn't lend themselves to being easily ported into the new version (at which point, maybe having to revamp the entire code structure anyway, they started thinking outside of the box?)
Off the top of my head: the "taller" commandbar. When MS first came out, the height of those commandbars was almost as tall as the ribbon is now (when everyone was using 640x480). The commandbar rows have effectively gotten smaller and smaller. But there is a need for those tiny buttons to be seen by aging eyes (we're not all 25 with perfect vision). I can't tell you how many people I see, over 60, with 30 inch monitors running at some ridiculously low resolution so they can see the buttons.
And despite the ability to make the buttons bigger, they may not have been able to leverage a higher graphic resolution. So maybe they had gone as far as they could in extending the life of a user interface designed around 640x480 and 800x600 screens?
Having spent at least one part of my programming life identifying core bugs in MS Word code, I will tell you it was surprising to me what parts were fixable and what parts weren't. Sometimes the bugs are deep enough that the only "solution" is a complete teardown and re-structure (I specifically remember one where selecting a table from the bottom right to the top left, instead of the top left to the bottom right would cause erroneous errors--that MS "remembered" how a selection was made, rather than just dealing with the selection was a surprise-- and also unfixable in that version).
I wouldn't be surprised to find out that was the original impetus for the Ribbon (although all of your points would certainly add in to the discussion as well).
Cheers,
-Jason
That may well be why we have a different perception. Most of my development has been in Excel. I have never liked Word development, or its object model, when compared to Excel, it just never seemed as logical.Quote:
Originally Posted by Frosty
Nor I, and in general I agree with your view.Quote:
Originally Posted by Frosty
Well that is what they say, the message they feed us. The reality seems different to me. Once, all the office teams developed their own interfaces, then the Office team got sway and they forced a 'uniform' style on all the products. You can see why a standard look and feel sounds good, but they haven't achieved it, and they went for the LCD. Look how they crippled charting in Excel 2007.Quote:
Originally Posted by Frosty
Why do you think that, what supports that view. They did it with commandbars, building a new paradigm from scratch should be easier.Quote:
Originally Posted by Frosty
Ran out of time? That is just poor project management then, which again supports my view that it is all income driven, they rushed it to market. 2007 is a release I have always recommended my clients giving a miss because it is so bad.Quote:
Originally Posted by Frosty
I have written many COM addins, but I am struggling to see how you would do this. If I get some time I will do some work on it, see if it does look possible.Quote:
Originally Posted by Frosty
Thanks for whatever time you spend looking up the alternate route on the COM Addin, xld.
As for why I think the ribbon thing would be significant coding... it's just a guess. Of course they could do it (and I'm guessing they will). But suddenly having to re-orient everything to be read top down rather than left right-- with the clear amount of time they devoted to the entire "autoscale" concept of the ribbon--I think that would take some time.
I think they spent a lot of time making a horizontal ribbon work in a variety of screen widths, and that they would need to spend an equal amount of time making a vertical ribbon work in a variety screen heights, to say nothing of whether they would need to adjust something in the various OS and they way they deal with sideways fonts.
As opposed to the commandbars, where almost every button was a fixed width... I think it would probably be a bit different. But just as a sample, if you take a commandbar in office 2003 which shows images and labels, and it looks nice... then dock it on the left or right, you can see the composting of the fonts looks terrible. It's readable, but it's not pretty. I just guess they chose not to have that half-ass implementation, because, fundamentally, if the ribbon isn't pretty-- then it doesn't have anything going for it ;)
I think that they will not do any further significant development on the ribbon. MS' Office team have moved on, we now have Office 365, Excel Services, self-service BI (PowerPivot) and integration with Denali and SharePoint. They are taking Office in another direction, and this requires their effort at a time where the economy means that they (MS) have lost a lot of people. When I say Office, I mean Excel for sure, I am not so clear what they have in mind for Word and/or Access (and I don't care what they have in mind for PowerPoint). From where I sit, Word seems to drive the Office team's thinking, which is odd seeing as Excel and Access are far more 'innovative' products. In 2007 I thought that Access looked doomed, come 2010 and it got a whole new lie.
I think you hit the nail on the head with this statement ... because, fundamentally, if the ribbon isn't pretty-- then it doesn't have anything going for it. As a developer, I feel it has little going for it, but that is yesterday's argument, it is here, other companies have adopted it (even though it rarely adds to their product (Snagit, Help & Manual, ...), so we just need to work with it as best we can. To be honest, I have found other things in 2007/2010 far more exasperating than the ribbon (conditional formatting, NameManager, etc.). I have had lots of fun playing with ribbon, notwithstanding that I think it is a poor paradigm and a poor implementation.
Thank you for your help.
________________________________________________________
Accesorios Coche
Universales Autodiagnosis
Elevadores Coches