|
The bluescreen isn't blue without a reason: You will find in a lot of books on graphic design that white on blue is one of the most readable color combinations. Black on yellow is another combination at the top of the list. I don't remember which of the two has the top score; it is a very close race.
So it should come as no big surprise that traffic signs very often are black on yellow or white on blue. Pink on black may catch your attention more easily, but if the text content is the essential thing, then green on black is far better, much more readable.
When I was still a student, I did all my programming green-on-black - we had no alternative (except for the card readers that were still available). A couple years later, black-on-white screens were introduced, but made no great success: Green-on-black, 25 lines of 80 chars, was the preferred choice until the arrival of VGA (and even a few years into the VGA era).
In my first job, when PCs had just been introduced, one of the old guys pointed to the Tandberg 2215 terminals: "Take a good look at these! You won't see anything that can match them, ergonomically, for the next ten years, at least." --- It turned out that he was right. Screens got more functions, more colors, more resolution, but it took more than ten years before we got the same readability, and even today, screens have higher functionality, but are no better ergonomically. (That is of course strongly affected by how we choose to use these screens - today, poor ergonomics are essentially caused by poor choices, not by screen technology.)
|
|
|
|
|
Black on yellow is tops I believe, that's why so many road signs are those colors.
|
|
|
|
|
That's been essentially my experience, too. Moreover, I cannot understand why anyone would pick a low-contrast color such as the stock blue color for text, when the default color scheme for most shells is black.
For years, I have considered attempting to devise an automated color picker that takes the active background color into account when it selects a foreground color.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I love the blue screen. Illegible red text on that blue drives me up the wall. Nobody that coded that colour combo ever used it themselves, on Windows at least.
It's not just Git Bash - the Posh Git extension that makes PowerShell a Git console has exactly the same horrific colour scheme.
"'Do what thou wilt...' is to bid Stars to shine, Vines to bear grapes, Water to seek its level; man is the only being in Nature that has striven to set himself at odds with himself."
—Aleister Crowley
|
|
|
|
|
Here are the responsible people: Family[^]
|
|
|
|
|
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
It seems that project managers like to think that they know best, and screw the experts. I remember a senior manager telling the head of the Human Factors group on the Comanche helicopter that a double press world work, which meant that did not need a pressure sensitive screen. Of course what he did not seem to take into account was that the helicopter would be shaking and maneuvering, so the crew member would have to keep his eyes on the screen for both touches, instead of being able to take his eyes off once he had identified the control with his touch. Look at the crap Microsoft has given us like the ribbon and metro.
|
|
|
|
|
With regard to Metro, I agree that it's mostly a load of crap. However, after almost a decade of daily use, starting when I transitioned from Office 2002 (Office XP) to Office 2010, I've grown accustomed to the ribbon, and I have an idea about why they adopted it, and are extending it into other parts of Windows, etc. Somewhat to their credit, they seem to have learned from some of their mistakes, and are grudgingly adding support for the old, trustworthy Windows widgets to the Metro (UWP) kit.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
Their implementation in Office basically sucked for year since it did not allow you to change it, and it hide functionality. All they had to do was keep the menu, possibly using a scheme like used in several programs where you just had to hit the alt key, and give users the option of showing the menu all the time. They wanted to force people to use the Ribbon so they gave no option. Instead should have provided it as the standard option and allowed users to decide what they wanted instead of dictating. I too have gotten use to the Ribbon, but I am not sure it is that much better than toolbars. That the menu and toolbars have their place is shown in even Microsoft applications still using these older concepts, and you see menus all the time in Web apps. Nobody seems to have bothered with the Ribbon concept in web apps, which to me shows it was not all that great a concept.
|
|
|
|
|
You aren't likely to see it in Web apps because it significantly increases the download bandwidth required to support the page, since those graphics are much larger than any text menu. Even using something as efficient as SVG requires more bytes to transmit than the text, most of which must be transmitted anyway, to convey the URL behind each button. CDNs can mitigate the cost somewhat, but it requires a good bit of extra infrastructure to use them under HTPPS.
Another reason you are unlikely to see ribbons in Web applications is that they consume far more screen real estate, which is contrary to Responsive design principles. In that regard, Google is pushing developers very strongly in that direction, and with good reason. Who knows, maybe we'll eventually get back to the simple predominantly text pages that dominated the early WWW.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
The screen real estate is an issue too, especially on smaller displays. It was a gimmick that was put out before it was ready, and totally destroying the old interface was another stupid Microsoft move since it just made it difficult on people. In the meantime things that they could have fixed that would have truly improved the product are still not made. You can see things in Microsoft products that are basically over 20 years old.
|
|
|
|
|
Yes; did you miss my mention of screen real estate in the 2nd paragraph?
Microsoft is a Big Company, and it suffers from most of the problems common to Big Companies. One of the most pernicious of those is group hubris. That's how you get things like pandering to new users, even at the expense of throwing loyal customers that paid your way under the bus.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
So far many of the products are not worth upgrading. Using office from 2 decades ago is not much different except the stupid ribbon made it impossible to get to features, a big down vote, and used a lot more real estate. Not sure I really thought that Windows 7 had to be replaced by windows 10
|
|
|
|
|
It didn't, apart from keeping the revenue stream going.
David A. Gray
Delivering Solutions for the Ages, One Problem at a Time
Interpreting the Fundamental Principle of Tabular Reporting
|
|
|
|
|
I've found that the best color scheme is subjective at best.
I recall one custom software project where I did everything the client asked for and he said, I don't know it just doesn't look right to me.
He was an immigranr running his own business. I went to the library and looked up the country he was from and adjusted the color scheme to match the colors on their flag. He loved it and immediately went to get everyone around the office so he could braag on his new software and he wrote a check for me immediately, and the bank recognized and paid the check, too.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
|
This is quite old. JS was brought in as a first-class language with Windows 8 (WinRT apps) already. Microsoft just continued it with UWP.
UWP does not need to implement the browser control - it is directly using Chakra + Trident.
This was one of the reasons why WinJS was formed (GitHub - winjs/winjs: A UI toolkit for modern browsers) in the first place.
|
|
|
|
|
Interesting. Yes I remember that now -- the old WinRT which lived for about 3 seconds.
Good info on the Chakra + Trident engine. thanks
|
|
|
|
|
As Florian explained, this is, indeed, old news.
However, it did deserved to end-up in that forum one day.... And now you have done it! 
|
|
|
|
|
|
MS should have just focused on one single language which is C#, than spread all the development efforts over other language/platform like C++/CX and Javascript.
C++/CX syntax is definitely not as inituitively as C# API. Take Array class for example,
byte[] arr = new byte[5];
arr[0] = 12;
byte n = arr[0];
Array<unsigned char>^ arr = ref new Array<unsigned char>(5);
arr->set(0, 12); unsigned char n = arr->get(0);
C++/CX needlessly expose many implementation details out while C# encapsulates those details. For example, C# string is converted to UWP Platform String automatically when calling UWP API, while C++/CX developer has to do this explicit step ourselves. Despite out for 5 years, C++/CX does not have async feature. So when C++/CX dev calls async UWP function, he has to manually spurn a worker thread to call it synchronously. Instead of introducing this half-baked language, efforts could have been better spent on one main language.
|
|
|
|
|
Cake Processor wrote: he has to manually spurn a worker thread
It's always good to spurn[^] things!
(I think you meant "spawn".)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Haha, you are right! 
|
|
|
|
|
|
Let me illustrate with the below code. mSource used to be local variable but it is disposed before it can be used in the 4th lambda. So I make this temporary variable as a class member to work around that problem.
void ClampImageApp::MainPage::btnOpenImage_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
FileOpenPicker^ fileOpenPicker = ref new FileOpenPicker();
fileOpenPicker->SuggestedStartLocation = PickerLocationId::PicturesLibrary;
fileOpenPicker->FileTypeFilter->Append(L".jpg");
fileOpenPicker->ViewMode = PickerViewMode::Thumbnail;
mSource = ref new SoftwareBitmapSource();
concurrency::create_task(fileOpenPicker->PickSingleFileAsync())
.then([&](StorageFile^ file)->IAsyncOperation<IRandomAccessStream^>^
{
if (file)
{
return file->OpenAsync(FileAccessMode::Read);
}
else
{
throw task_canceled();
}
}).then([&](IRandomAccessStream^ stream)->IAsyncOperation<BitmapDecoder^>^
{
return BitmapDecoder::CreateAsync(stream);
}).then([&](BitmapDecoder^ decoder)->IAsyncOperation<SoftwareBitmap^>^
{
return decoder->GetSoftwareBitmapAsync();
}).then([&](SoftwareBitmap^ sw_bmp)->IAsyncAction^
{
if (sw_bmp->BitmapPixelFormat != BitmapPixelFormat::Bgra8 ||
sw_bmp->BitmapAlphaMode == BitmapAlphaMode::Straight)
{
sw_bmp = SoftwareBitmap::Convert(sw_bmp, BitmapPixelFormat::Bgra8, BitmapAlphaMode::Premultiplied);
}
return mSource->SetBitmapAsync(sw_bmp);
}).then([&]()->void {
this->imgPhoto->Source = mSource;
});
}
This is the C# code to use composite value
Windows.Storage.ApplicationDataContainer localSettings = Windows.Storage.ApplicationData.Current.LocalSettings;
Windows.Storage.ApplicationDataCompositeValue composite = new Windows.Storage.ApplicationDataCompositeValue();
composite["intVal"] = 1212;
composite["strVal"] = "string";
localSettings.Values["RawCompositeSetting"] = composite;
Windows.Storage.ApplicationDataCompositeValue composite2 =
(Windows.Storage.ApplicationDataCompositeValue)localSettings.Values["RawCompositeSetting"];
And compared to C++/CX equivalent code
Windows::Storage::ApplicationDataContainer^ localSettings =
Windows::Storage::ApplicationData::Current->LocalSettings;
ApplicationDataCompositeValue^ composite = ref new ApplicationDataCompositeValue();
composite->Insert("intVal", dynamic_cast<PropertyValue^>(PropertyValue::CreateInt32(1212)));
composite->Insert("strVal", dynamic_cast<PropertyValue^>(PropertyValue::CreateString("string")));
auto values = localSettings->Values;
values->Insert("RawCompositeSetting", composite);
ApplicationDataCompositeValue^ composite2 = safe_cast<ApplicationDataCompositeValue^>(localSettings->Values->Lookup("RawCompositeSetting"));
UWP is a native platform where native C++/CX is orders of magnitude slower than managed C#. Not sure how that is possible. Microsoft just developed a new C++ language to replace C++/CX, called C++/winrt which has async/await and much better performance and full C++ standard compliant. But it is not ready yet as 2 months ago, I found VS cannot build a newly generated C++/winrt project without errors and it does not support win2D.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
