Designing GitHub for Windows(github.com)
github.com
Designing GitHub for Windows
https://github.com/blog/1151-designing-github-for-windows
41 comments
> but you can't just go in and add a single line to change the color of an invalid toolbox border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
This is spot on. The point of a declarative markup language is to make hand editing easy, but XAML fails hard on the simplest of tweaks.
This is spot on. The point of a declarative markup language is to make hand editing easy, but XAML fails hard on the simplest of tweaks.
Personally I've always found XAML and C# to be an incredibly productive programming environment. I wish I could work with the MS tool chain more often.
I disagree. I haven't worked in XAML for a few years and I wouldn't recommend it on almost any application (unless a windows specific desktop). But the only reasons I don't recommend it is because it is windows specific.
Aside from that the true power of xaml is it allows you to change anything. For example, A radio button group, checkbox list, drop down, expandable list or searchable list could all derive from the same basic component AND same set of data. In html that would be like saying this (warning, lots of fake code below)
<div class="dropDown" data="['frank','sam','larry']"/>
<div class="expanderBar" data="['frank','sam','larry']"/>
<div class="radioButton" data="['frank','sam','larry']"/>
<class id="radioButton"> <div style="border:1px solid black"> <loop value="data" var="item"> <input type="radio" name="user" checked="condition">${item} </loop> </div> </class>
...and so on
That is COOOL and it has been around since XAML was created. We've tried to get to the same place with jquery templates but they have always been hackish approaches to templating/styling
Aside from that the true power of xaml is it allows you to change anything. For example, A radio button group, checkbox list, drop down, expandable list or searchable list could all derive from the same basic component AND same set of data. In html that would be like saying this (warning, lots of fake code below)
<div class="dropDown" data="['frank','sam','larry']"/>
<div class="expanderBar" data="['frank','sam','larry']"/>
<div class="radioButton" data="['frank','sam','larry']"/>
<class id="radioButton"> <div style="border:1px solid black"> <loop value="data" var="item"> <input type="radio" name="user" checked="condition">${item} </loop> </div> </class>
...and so on
That is COOOL and it has been around since XAML was created. We've tried to get to the same place with jquery templates but they have always been hackish approaches to templating/styling
The majority of people that I've heard criticize XAML are people who are just starting out with it (and hence are clueless, literally).
Everyone else, including myself, see it for what it is, one of the best ways to build up, iterate/change, and maintain a UI.
Nothing else even comes close.
edit: I write XAML mostly manually, not via a designer. I also don't subscribe to any particular rule-set about using or not-using code-behind, particular ways of databinding, etc.
Everyone else, including myself, see it for what it is, one of the best ways to build up, iterate/change, and maintain a UI.
Nothing else even comes close.
edit: I write XAML mostly manually, not via a designer. I also don't subscribe to any particular rule-set about using or not-using code-behind, particular ways of databinding, etc.
I've been working with XAML for years on a regular basis. It sucked in 2009, and it still sucks now.
It quickly progresses past hand editing on any project of any significant complexity. (Read: a real app) So Blend is required, especially if you're doing animations. VS is only slightly better than notepad for XAML.
XAML parsing is consistently broken in Blend and VS, so bad markup breaks the entire file without any meaningful error message. On a related note, it is very difficult to make "Blendable" XAML files. Wiring up data-binding kills blendability. You end up opening a lot of "blank" files in the designer.
MVVM is a pattern to avoid having to deal with XAML.
XAML is more of a human-readable file format than a presentation markup language. You have a lot of information about the app/state mixed in with the UI markup. You need to have a solid understanding of the C# underneath to use XAML properly.
Designers should NEVER be allowed to produce their own XAML, especially in Blend. It's worse than Frontpage. The cake is a lie. Designers still live in Photoshop and Illustrator. Programmers are actually the main users of Blend. The root problem is that you can't produce usable XAML without also knowing C# and the .NET Framework. In other words, you have to be a programmer to generate XAML in Blend. Fail.
It quickly progresses past hand editing on any project of any significant complexity. (Read: a real app) So Blend is required, especially if you're doing animations. VS is only slightly better than notepad for XAML.
XAML parsing is consistently broken in Blend and VS, so bad markup breaks the entire file without any meaningful error message. On a related note, it is very difficult to make "Blendable" XAML files. Wiring up data-binding kills blendability. You end up opening a lot of "blank" files in the designer.
MVVM is a pattern to avoid having to deal with XAML.
XAML is more of a human-readable file format than a presentation markup language. You have a lot of information about the app/state mixed in with the UI markup. You need to have a solid understanding of the C# underneath to use XAML properly.
Designers should NEVER be allowed to produce their own XAML, especially in Blend. It's worse than Frontpage. The cake is a lie. Designers still live in Photoshop and Illustrator. Programmers are actually the main users of Blend. The root problem is that you can't produce usable XAML without also knowing C# and the .NET Framework. In other words, you have to be a programmer to generate XAML in Blend. Fail.
The root problem is that you can't produce usable XAML without also knowing C# and the .NET Framework. In other words, you have to be a programmer to generate XAML in Blend. Fail.
That's like complaining about gravity or friction or taxes. Give me an example of a software tool that non-programmers can use to generate working software and I'll eat my hat.
That's like complaining about gravity or friction or taxes. Give me an example of a software tool that non-programmers can use to generate working software and I'll eat my hat.
> Give me an example of a software tool that non-programmers can use to generate working software
XAML isn't working software. It's markup. UI.
For an example, I've seen designers generate great HTML+CSS (and then leave the data queries and ajax post to coders who don't have the same design sense).
Designers use tools, and they edit the resulting textual markup by hand. Because understanding that markup and having an aesthetic sense about when it "looks good", has low repetition etc is part of their skillset.
XAML isn't working software. It's markup. UI.
For an example, I've seen designers generate great HTML+CSS (and then leave the data queries and ajax post to coders who don't have the same design sense).
Designers use tools, and they edit the resulting textual markup by hand. Because understanding that markup and having an aesthetic sense about when it "looks good", has low repetition etc is part of their skillset.
Flash. Non-programmers produce all sorts of crazy things with very little code or understanding of programming.
[deleted]
It does have it's bad spots, but I really don't see how something can "suck" when 1) it works and 2) every single other alternative is light-years behind.
If you are coding and not working with designers or using Blend, sticking with plain-old C# is better. WPF/WinRT/Silverlight are just great APIs, that they are somehow associated with XAML is orthogonal (my personal opinion, not speaking for my employer).
I agree. I was exposed to C#/XAML a few months ago by building a WP7 Application. It takes some getting used to, but when you get the basics it's great. I'd kill to have something similar instead of HTML/CSS (which is just awful in comparison) for the web.
Please keep your ad hominem for other parts of the web.
"clue-less": without any clues about the workings and mis-workings (parts to stay away from) of XAML/WPF...
Clues come from experience. And without experience, just starting out on a subject, makes you clueless about it.
Clues come from experience. And without experience, just starting out on a subject, makes you clueless about it.
While they may be technically correct, words like "clueless", "naive", or "ignorant" can be really aggressive and feel like ad-hominem.
A more constructive phrasing might have been:
The majority of people that I've heard criticize XAML are people who are just starting out with it and don't fully understand what it has to offer
A more constructive phrasing might have been:
The majority of people that I've heard criticize XAML are people who are just starting out with it and don't fully understand what it has to offer
My beef with XAML is it's a whole other language aside from C# into which the semantics of C# and WPF had to be mapped. Worse, the constraints of XAML affected the design of WPF itself. I.e. the tail wagged the dog.
If C# had hygienic macros, I think the syntax of C# could have been extended for WPF specific needs, without having to resort to an XML based solution.
With a few extension methods, C# can come close and sometimes exceed XAML in its concision. I've been collecting these in a FluentWpf (https://github.com/dharmatech/FluentWpf) project on GitHub.
An example: http://stackoverflow.com/questions/1347219/are-there-any-flu...
If C# had hygienic macros, I think the syntax of C# could have been extended for WPF specific needs, without having to resort to an XML based solution.
With a few extension methods, C# can come close and sometimes exceed XAML in its concision. I've been collecting these in a FluentWpf (https://github.com/dharmatech/FluentWpf) project on GitHub.
An example: http://stackoverflow.com/questions/1347219/are-there-any-flu...
But XAML was intended from the start to play well with visual design-time tools, and C#-with-macros would probably have been too expressive to be roundtripped reliably through Blend and the VS designer.
C# with an ordained set of macro based extensions intended for use with WPF would work fine with a visual designer like Blend and the VS one. The visual designers would be the ones generating this code, so they'd know how to parse it.
[deleted]
I personally like XAML. What part of it do you think was a let down?
i actually like xaml. can i ask what parts of it makes xaml let down?
from my main post edit:
edit: Some people have asked why I didn't like XAML. My pragmatic concern has to do with the workflow and design of UI elements. You shouldn't need blend to edit validation styles efficiently. I know you don't need blend, but you can't just go in and add a single line to change the color of a border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
CSS is infinitely more simple than XAML style resources.
I'm also very partial to the pseudo separation of concerns where HTML is for semantics, and CSS is for style, and JS is for effects. Tying all of those things into one XML based language just doesn't make sense.
That said, the whole MS C# stack has really been great to work with outside of XAML and its default elements.
edit: Some people have asked why I didn't like XAML. My pragmatic concern has to do with the workflow and design of UI elements. You shouldn't need blend to edit validation styles efficiently. I know you don't need blend, but you can't just go in and add a single line to change the color of a border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
CSS is infinitely more simple than XAML style resources.
I'm also very partial to the pseudo separation of concerns where HTML is for semantics, and CSS is for style, and JS is for effects. Tying all of those things into one XML based language just doesn't make sense.
That said, the whole MS C# stack has really been great to work with outside of XAML and its default elements.
Scott Hanselman also got Tim Clem and Phil Haack talking about this on the recent podcast, http://hanselminutes.com/320/developing-github-for-windows-w...
A beautiful piece of software and a great help for those of us that loathe the command line. I was just looking through GitHub today trying to figure out how the look was achieved since I couldn't find any Metro controls in VS.
I really like the native development approach for UI, too often the design of ported apps feel like an after thought, unless your on the OS it was originally developed on
[deleted]
Genuine question, did Github consider doing a local web app? If I want to browse my local code I may be more familiar with the HTML interface.
I kind of wonder if Spotify for Windows would have benefited from these design decisions. I'm happy to see that Github embraced the OS/platform rather than treat it as an ugly inconvenience. I'm very much platform agnostic, but when something works well on one platform and then terribly, or sub-optimal, on another, I feel like the programmers are making some statement about their preferred OS/platform rather than making solid software.
AFAIK, Spotify's "app" is mostly a Chromium shell on all platforms.
Indeed. It feels surprisingly native despite this, though.
It's nice to see Github building apps for each platform, without taking shortcuts. It's so much more pleasant to build AND use native apps with things like XAML and the Metro UI vs. making kludgy HTML shell apps.
Spot on, it about time people realize that HTML apps are a kludge.
HTML is for documents.
HTML is for documents.
Now if only they can fix the constant crashing and then I'll be happy. No point in having a nice design if the application crashes so much that people can't see it.
Send us an email at [email protected] if you are having trouble and we'd love to sort it out.
Anyone else find the font, especially the bold, grating? I don't think it's just the rendering but also the size and actual font (feels so big and cluttered in that merge request page).
I wonder if I'm the only one who doesn't really like the GitHub Windows user experience?
The most confusing thing is what you see when you select a repository. It shows you the commit details and diffs of the latest commit. That makes you feel like something is wrong or pending so you need to respond to it. The latest commit and its diffs are really not the main point of interest in that situation.
I would much prefer to see a tree view of the current files in the repo (and maybe the README), just like on GitHub. That would be the most natural way of browsing the files, opening them by clicking, and seeing what has been modified.
That would make you feel that you are in control and understand what's going on right from the beginning. Even if you're a newbie or non-tech guy.
The most confusing thing is what you see when you select a repository. It shows you the commit details and diffs of the latest commit. That makes you feel like something is wrong or pending so you need to respond to it. The latest commit and its diffs are really not the main point of interest in that situation.
I would much prefer to see a tree view of the current files in the repo (and maybe the README), just like on GitHub. That would be the most natural way of browsing the files, opening them by clicking, and seeing what has been modified.
That would make you feel that you are in control and understand what's going on right from the beginning. Even if you're a newbie or non-tech guy.
That annoys me too. Also the cryptic error messages, the Windows client is (I assume) for people that aren't all that familiar with git and would prefer a UI so when my commit fails and I get an error message that a) when googled produces 0 results b) doesn't link to a help doc and c) has "open shell" as the solution it's very frustrating.
Good to see a bit of love for XAML and WPF on HN. I've been developing with it for the past 2 years - don't know how I worked without it.
XAML has just been total let down since I've had to learn it for an ongoing Silverlight project.
edit: Some people have asked why I didn't like XAML. My pragmatic concern has to do with the workflow and design of UI elements. You shouldn't need blend to edit validation styles efficiently. I know you don't need blend, but you can't just go in and add a single line to change the color of an invalid toolbox border--the alternative to blend is to (afaik) copy the entire style resource that the element uses from MSDN, dig into it to find the appropriate 10 lines of useless markup that surround one word property.
CSS is infinitely more simple than XAML style resources.
I'm also very partial to the pseudo separation of concerns where HTML is for semantics, and CSS is for style, and JS is for effects. Tying all of those things into one XML based language just doesn't make sense.
That said, the whole MS C# stack has really been great to work with outside of XAML and its default elements.