Entries:
Comments:
Discussions:

Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Discussions

bondsbw bondsbw
  • Microsoft Kill Off Windows Phone

    @DeathByVisualStudio:  I don't know about the ribbon control (never liked it enough to even try) but adaptive triggers in UWP seem to be pretty simple.  Tell it what causes the state to trigger (windows size above a certain point), and what to change.

    <VisualState x:Name="Wide">
        <VisualState.StateTriggers>
            <AdaptiveTrigger MinWindowWidth="900" />
        </VisualState.StateTriggers>
        <VisualState.Setters>
            <!-- Keep SplitView pane always showing inline -->
            <!-- Hide the Hamburger, it's useless here -->
            <Setter Target="MySplitView.DisplayMode"
                    Value="Inline" />
            <Setter Target="MySplitView.IsPaneOpen"
                    Value="True" />
            <Setter Target="HamburgerButton.Visibility"
                    Value="Collapsed" />
        </VisualState.Setters>
    </VisualState>

  • Microsoft Kill Off Windows Phone

    , cbae wrote

    The only problem is that the "pointing device" that you use on a phone is gigantic relative to the display size, so addressing the text size isn't all that you need to worry about.

    And as I stated before, UWP is adaptive to input as well.  Larger menu items for touch vs. smaller ones for mouse.  Different strategy when an Xbox controller is in use.  And so on.

  • Microsoft Kill Off Windows Phone

    What you linked is "Auto Layout", and it appears to be roughly equivalent to the margins and padding that have been in XAML since the beginning.  No, that is not what I'm talking about.

    I'm talking about changing any part of the layout or content you want.  If the windows is less than 800epx wide, content that was layered horizontal becomes vertical.  Buttons get moved from the right to the bottom.  A sidebar of selectable content is moved into drop-down.  Description text is trimmed or eliminated.

  • Microsoft Kill Off Windows Phone

    @magicalclick:  UWP accomplishes it with effective pixels which takes into account not only the pixel density of the display, but also the typical viewing distance, to normalize the perceived size.

  • It would still be a travesty had they been awarded $1

    , fanbaby wrote

    its patents are very meaningful (slide to unlock anyone?)

    Ha.  Haha.  Hahahahaha!

    THAT is meaningful?

  • Microsoft Kill Off Windows Phone

    , Ray7 wrote

    But this is pretty much how it works on Apple gear. You can have a fat binary that holds different layout templates and controllers for the iOS or tvOS and pick the set at runtime.

    But that's not what is happening here.  Your code literally adapts to the size of the container.  For example, if your app is run maximized on a large display, elements are arranged in one format.  As you decrease the size, at some point the elements may rearrange to a different size.  Or perhaps they resize fluidly as the container becomes smaller with no jumps.  Maybe some functionality gets moved into a menu, or gets removed altogether as it doesn't make sense at that size.  It's all up to the developer.

    And it's not just about whether it's a phone vs. tablet vs. desktop.  A desktop user could snap a window to the side, and the resizing logic would kick in to display a usable window (often the same as the phone layout).  This is tons better than resizing a desktop window and cutting off most of the content, or not allowing smaller windows at all.

  • Microsoft Kill Off Windows Phone

    @Ray7:  Again, you're not running a phone UI on desktop.  You are adapting the UI to run optimally on phone or a desktop, in the same way that websites often do.

    Continuity and Continuum are completely different concepts.

  • Microsoft Kill Off Windows Phone

    @Bass:  Wait, didn't Microsoft invest in $300 million in B&N's Nook subsidiary?  I think the Nook failed due to competition.

  • Microsoft Kill Off Windows Phone

    , Bass wrote

    If it's about having two binaries that share code, that's nothing special at all. Phone and desktop sync is solved by "the cloud". Continuum only serves to encourage people to crap their pants even harder if they ever forget their phone at home.

    It's about choice and options.  Just because I can write one platform-independent UWP app that gets deployed everywhere, that doesn't mean I have to.  I can certainly write platform-dependent UWP apps with shared libraries if that is a better fit for my needs.

  • So Joe Belfore is using iPhone right now.

    I just don't see businesses flocking to the iPhone because it is the best business device that could possibly be.  It's popular; they reluctantly support it.

    Windows phones aren't even popular, and until Continuum (which is very new) MS hasn't offered enough features that are than the iPhone is for business.  Their only hope is to blow away the competition with new capabilities, and I think they can do that by targeting business customers and business use cases.

    An example is data entry, where Apple hates the thought of combining a physical full-size keyboard with their precious, beautiful iPhone.  Maybe MS can exploit that, and come up with some revolutionary mobile, full-size keyboard that integrates seamlessly with their phone, is easy to carry around, and can be used without a desk or table.  Maybe they can be first-to-market with some of the flexible display panel technology that would make expanding from a 5-inch screen to a much larger display possible within the confines of a pocketable device.