Office UI Fabric by Microsoft(dev.office.com)
dev.office.com
Office UI Fabric by Microsoft
https://dev.office.com/fabric
29 comments
Coming from windows (trying out mac), I have run into instances where (as I'm so used to the MS way) it's actually kind of jarring seeing dialogs that don't follow that "Don't" suggestion.
Granted, I haven't used much new MS software lately, so if they've gotten worse about that as you say that's a shame.
Granted, I haven't used much new MS software lately, so if they've gotten worse about that as you say that's a shame.
One of the things I remember about moving to Mac was dialogs without a "cancel"-button.
I always get infuriated by custom UI components, because they are always poorly implemented for keyboard accessibility. Always. I have never met an exception. Seriously, is it that hard to copy the platform behaviour for keypresses, &c.? Sure, some of the details vary by platform, but it shouldn’t be difficult to get the vast majority of it right. Especially for Windows, given Fabric’s primary target.
Fabric is still no exception, though I find it better than the alternatives in almost everything.
(The menu bar component that seems to be used with Electron apps is extremely irritating in its keyboard handling: left and right arrow keys don’t let you switch between menus like they should.)
Fabric is still no exception, though I find it better than the alternatives in almost everything.
(The menu bar component that seems to be used with Electron apps is extremely irritating in its keyboard handling: left and right arrow keys don’t let you switch between menus like they should.)
i have a little experience in this. The shortcut keys don't just vary by platform but can also vary by region / keyboard config. Ctrl-I might do italic text in your version of word, but it might do something else in another region, where italic does not start with I.
Getting THESE consistent is very complex. Granted some (like arrow keys) could be done better, though in the case of electron this is part of webkit and not a separate component, so app developers (I'm pretty sure) have no control over it
Getting THESE consistent is very complex. Granted some (like arrow keys) could be done better, though in the case of electron this is part of webkit and not a separate component, so app developers (I'm pretty sure) have no control over it
Office shortcuts do not tend to vary with region unless you have a complete IME installed for Office as well (and even then most of them stay the same), and IIRC this is only available for only a few edition of Office, and I'm not sure if the past 2-3 versions even had that.
Overall the rule of thumb is that anything that is ctrl/winkey + key will stay the same, what Windows changes with the region is the alt shortcuts when you click alt + the a letter key it will use a UI component (usually) starting with that letter this is a literal shortcut rather than a functional one and it's fully converted via IME (IIRC MSFT even has an API that does this automatically), ctrl shortcuts are not literal, some are but mostly due to a coincidence rather than intent.
e.g. ctrl c - for copy, but x and v for cut and paste are there for ease of use due to the location while if you do with with alt then it will be Alt + E for the Edit menu, then C for Copy, T for cuT and P for Paste.
Overall the rule of thumb is that anything that is ctrl/winkey + key will stay the same, what Windows changes with the region is the alt shortcuts when you click alt + the a letter key it will use a UI component (usually) starting with that letter this is a literal shortcut rather than a functional one and it's fully converted via IME (IIRC MSFT even has an API that does this automatically), ctrl shortcuts are not literal, some are but mostly due to a coincidence rather than intent.
e.g. ctrl c - for copy, but x and v for cut and paste are there for ease of use due to the location while if you do with with alt then it will be Alt + E for the Edit menu, then C for Copy, T for cuT and P for Paste.
It took me a while to understand what this is and I am still not sure. IT seems like a CSS/JS component framework like Bootstrap but themed based on Microsoft Office design language? Is there any other relation to Office other than that?
Yeah, this is probably meant to be used for their "Office Store" Add-ins. You could think of them as web apps that are "iframed" into Office applications.
They have a store full of these web add-ins at https://store.office.com/en-001/appshome.aspx?ui=en-US&rs=en... and dev docs at https://dev.office.com/docs/add-ins/overview/office-add-ins
They have a store full of these web add-ins at https://store.office.com/en-001/appshome.aspx?ui=en-US&rs=en... and dev docs at https://dev.office.com/docs/add-ins/overview/office-add-ins
Additionally the app it's embedded in can be driven. Kind of like vba.
It's like google apps for google docs
It is really frustrating to develop Office 365 Apps (pretty limited APIs) so I don't understand why they are not spending more resources on the API rather than the UI aspect. It seems like Microsoft is an unconnected company without cohesion.
For example, you cannot have an event that notifies you when a new e-mail arrives... and this issue is only the beginning.
For example, you cannot have an event that notifies you when a new e-mail arrives... and this issue is only the beginning.
Considering how large Microsoft is, I can't help but imagine that they have different engineering teams on each of those projects already.
I'm sure the frontend engineering team was excited about this, but somebody needs to give the backend engineering team a push
I'm sure the frontend engineering team was excited about this, but somebody needs to give the backend engineering team a push
Considering how large Microsoft is I can't believe they can't organize the company better. You need a product manager that have the whole vision about their different offerings.
The point is more that the resources that would make this are different from the resources that would better the API.
Complaining about resources going towards this rather than that are silly, with that in mind.
Complaining about resources going towards this rather than that are silly, with that in mind.
It seems you never worked with OWA Office Addins, they are not prehistoric but unusable.
I can complain all I like because I am a Microsoft customer, premium MSDN, etc.
I can complain all I like because I am a Microsoft customer, premium MSDN, etc.
In Microsoft's world, isn't that done through their Flow API?
I would drop the fade effects if I were MS. I can't be the only one who notices how bad most "effects" look in the browser. It reminds me even more that I'm not in a native platform.
When making UWP apps with web tech, should Fabric be considered a successor for WinJS, a good technology to use? Sure, it’s designed for Office UI, but there’s rather a lot of overlap in it with Windows design guidelines.
Perhaps a variant of it? It’d be good if Microsoft made the situation clear.
Perhaps a variant of it? It’d be good if Microsoft made the situation clear.
If I am not terribly mistaken, WinJS has been declared obsolete by MS themselves. So Fabric is your new bet if you 're willing to take one ;)
This is pretty snazzy. Looks like they're taking bootstrap concepts a step further with implementations for varying platforms. It's clean and simple design. I dig it.
Still trying to figure out how to add a simple function to Excel. This is an old attempt at adding a function `double` that doubles it's argument. http://kalx.net/ExcelUDF.html
Seems to no longer work.
hmmm... looks interesting. I've struggled with quirks of frameworks implementing Material UI in React - I'm guessing mainly because the frameworks don't have a large company supported team. Will try this out.
Does it have a progress bar component that goes backward like in Windows :) ?
> "Community-driven project with for Angular apps"
Grammar.
Grammar.
Yay, large attack surface!
So nowadays VBA is replaced with ES6 and React?
Still no cure for VBA though.
Hah!
Hah!
Do
Make sure the label conveys a clear purpose of the button to the user.
Button labels must describe the action the button will perform and should include a verb. Use concise, specific, self-explanatory labels, usually a single word.
Buttons should always include a noun if there is any room for interpretation about what the verb operates on.
...
Don’t
Don't use generic labels like "Ok," especially in the case of an error; errors are never "Ok."
Don’t place the default focus on a button that destroys data. Instead, place the default focus on the button that performs the "safe act" and retains the content (i.e. "Save") or cancels the action (i.e. "Cancel").
Pity that MS doesn't always follow them...