I'm working on migrate a project Ext4 -> Ext5.
Beta users reasonable noticed, that current spinner fields with up&down triangles on touch devices are very hard to be used. They has small sizes and it will be much better to have (-) and (+) buttons rights instead.
Basically it is already done in Sencha Touch 2.4 or early and (in theory) may borrow (s)css from touch themes to ExtJS
I wonder may somebody did this trick ? Or maybe there is a separate component?
meantime the issue is solved and it is very simple. Just need to use `ext-neptune-touch' or 'ext-crisp-touch' themes to get triangles away.
Related
I'm looking for dock layout engine for angularjs written in typescript. I found Dockspawn but it is written in DART and it's not compatible with the rest of my project. Does somebody know any dock layout engine (even paid ones) for angularjs in typescript?
I think your real problem is that dockspawn was abandoned. This is something I built at my company (which, sorry, we don't sell software)and it turns out that Angular is the worst thing you could use to build a layout engine like this.
Managing scope chains among components that are constantly changing positions, opening/closing, resizing, and floating is entirely too complicated for this type of project. You will end up with 15 step bug reports everywhere, and unless you have a perfect algorithm set in place before ever developing anything you will end up spending weeks re-writing code.
Solution (and not the one you want to hear): drop it. Web design is meant for developing pages within the browser, not for developing windows with tabs within your browser window which is full of tabs. The control and flexibility is very nice, but there is always a way to provide the user with just as much control by setting up panels on the page in the positions in which they will be consistently used the most.
Sooner or later someone will develop what you are looking for and release it, but it probably won't be in Angular and it's definitely going to cost money.
You should be able to use Dockspawn because at runtime DART is JavaScript, so as TypeScript. You just need to find a way to make TypeScript aware of Dockspawn and you can do that using a Type definition file.
The types definition file for Dockspawn is available online.
You can install this kind of files using a tool known as tsd. You can find a basic example here.
I have a web app that is built aimed primarily at iPads on full screen mode. I've got to implement a select-able grid/matrix that has two levels of selections - one main item selection and one sub item selection. It looks something like this from our design:
First picture has main item selection, and
The application is built on AngularJS, and Bootstrap3. Right now we have implemented a working version of the grid using a custom jQuery plugin we authored and now are wondering why we ever did it. The code is buggy and constantly throws up new bugs. We are looking for an alternative form of implementation, hopefully a pure AngularJS one.
The criteria we're looking for are:
1. Responsiveness across devices - iPad/desktop
2. Stable DOM structure compatible with filtering (search bar at the top needs to work - not shown in figures).
3. Quick rendering from dynamically changing AJAX data.
4. Touch friendly
What are the best methods/ng-modules to implement something like this? We are on the verge of deciding to write a custom module, but don't wanna reinvent the wheel!
We did see ng-grid, but it still seems to be in Beta. We need a stable module.
SmartTable seems to be the most decent option as of now.
TIA!
Have you Tried Angular Material Gridlist I think it must something more clean. I frequently use it rather than bootstrap. Hope it helps
Take a look at Angular Grid. I know it works on iPad, the scrolling uses touch gestures. It performs very well in comparison to other AngularJS grids. I've used it with large grids on iPads and Androids.
Go for Ionic Framework in conjuction with angular-material.
Both have you covered in terms of UI elements and grid needs, and are very reliable. Both are very active frameworks.
They both reached v1 very recently.
You should seriously consider the time you're going to gain, even if at first you have to drop Bootstrap. I was anxious as well to drop ui-bootstrap, but really, you won't regret it (and you'll be wondering why you didn't do it before).
Docs are impeccable, Codepens and Plunkrs are all over the place, Blog posts abound...
Learning curve is... well... judge for yourself.
I'm developing an app with Storyboard on iOS 6.1 (with many features - star ranking, sqlite DB, apple maps, etc..). Sometimes It happens that I have to disable the auto layout (for UIScrollView for example) or use code to work around the problem, but there are other examples. However when I disable it, I have to configure the UILabels with the exact width or other things.
What is the best option? Use auto layout or don't use it on iOS 6.x with Storyboard?
Autolayout, like many other features added to ios in recent years (arc and storyboards, for instance) was designed to ease development for both people who're just getting started in the iOS/Mac platform or for people who are already there but don't come from the old days of NeXT or OS X's infancy and thus could use some simplification to the whole development workflow.
One thing you could do is use autolayout by default, therefore making easier to write ViewControllers that perform both in portrait and in landscape, and disable it on those rare ocassions where you're more comfortable keeping everything using the old system of springs and struts. Another thing you can do is to also add Autolayout constraints in code instead of through Xcode's Interface Builder, if that suits your style better.
My advice is to use whatever system makes you more comfortable, no matter what the current trend is.
I don't use autolayout, because it's raw now. If you order constraints and then decide to move an element, you can get a real mess.
It's much safer to use springs and struts at this moment.
Upd.: But it's OK to use it in iOS7 - there are a lot of helpful tools for it in Xcode 5.
Honestly, this is up to preference but I never use auto layout and I doubt that I ever will. I guess I just prefer everything being exactly how I specify it and I don't trust auto layout.
I'm a big fan of Zurb Foundation. They just released Zurb Foundation 4 which was redesigned to be mobile first. I'm fairly new to responsive design taking into account both mobile, tablet, and traditional desktop experiences. I'm trying to wrap my head around how best to manage my site's content for these different devices. With Zurb Foundation 4, you can hide or show content based on small, medium, or large device sizes. So, it seems with Zurb's approach you drop all of the content down to the device and let the CSS decide what content to show depending on device (this is responsive design).
My question is why do we have to drop all of the content to the device? That seems like a waste of processing on the server, a waste of bandwidth, a slower experience as the browser handles the content some of which may never be shown to the user because of the device they are using. Am I missing something? Wouldn't it be better to go back to the server and let it send content to the client that's appropriate for the device type? Shouldn't we be concerned about mobile user's data plans and not send down content that's not appropriate for their device type? All the examples that I've seen on responsive design has content for desktop and mobile/tablet downloaded to the client which seems to be a waste.
I'm developing a time entry application that has a different user experience based on the device type. Desktops (when in full screen) have a more detailed data entry experience whereas mobile/tablets have a different experience because of device real estate is smaller. I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate? I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
Am I on the right track with my jQuery approach? Am I missing something regarding responsive design and needing to tailor the content to the device? Any ideas, suggestions, and guidance is appreciated. Thanks.
Mobile First with Zurb Foundation is basically a philosophy change by the Zurb team and if you want do develop a responsive site and not take a Mobile First approach then I suggest using Foundation 3 which is still available and fantastic. There is a book that I am reading that gives a great pitch for Mobile First, called Mobile First by Luke Wroblewski who is also listed as an adviser to Zurb.
here is an article by the same author that might be interesting:
http://www.netmagazine.com/interviews/luke-wroblewski-mobile-first
Basically: the premise is that you start your development and design for a mobile, meaning basically an iOS or Android style browser and then add features.
So instead of starting with a desktop / tablet experience and removing things as was commonly done with .hide classes in foundation 3 and could still be implemented in this way with foundation 4, they suggest using .show classes to add additional content.
This can be taken way further by using Compass and Sass Mixins. There isn't a lot of great documentation on how to do this, but you can basically keep your markup semantic, apply an id rather than a class and use the mixins to apply it to that id. There are advantages here in speed traversing the dom for an id vs. a class so it can be a good way to go.
Note: foundation 4 is using the drop in replacement (there are some limitations) for jQuery called Zepto. You can replace Zepto with jQuery if you really need it in foundation 4 or use foundation 3 instead. Zepto is much more lightweight and thus suited well for mobile.
As for it being faster by using jQuery to async load the data (I am assuming) based on the size of the browser, that is one way to do it. I am not sure if you are going to have a huge speed increase here. There are many strategies, pagination, async loading more data on the fly, and it depends on how you arrange the UX / UI around that data.
There are also many other issues such as caching resources, CDN, etc. that are typical in front end engineering that might give a faster load time. One resource you can check out related to this is ySlow.
There are also many design patterns such as off canvas slides, the 3 line (hamburger menu), loading more data on scroll, stateless apps, that can allow you to have the same functionality in a mobile app. If you go stateless, after the initial page load other pages should appear to be almost instantaneous.
I think the question here is more philosophical, in do you need all of the features, which is one thing that I believe taking a Mobile First approach is trying to approach.
Another thing to think about is the perceived loading time. I think I read about this is Seductive UX (another great read) but the faster you can get the page up with a loader or spinner, the faster it is perceived to be loading, even when in actuality it can be loading slower.
As a final note, if you plan on using foundation, you might look into using jQuery/Zepto with Modernizr to pull from the same media queries foundation is using. That way you don't duplicate or create something that is inconsistent with the rest of the responsiveness.
I'm developing the app so when the desktop browser is resized to something smaller that 768px wide that jQuery makes a call to the server to swap out the UI for the "smaller" mobile/tablet version. Is this appropriate?
It doesn't sound like a good approach do you take orientationChange in to account?
I certainly do not want to download 2 versions of the app and hide one or the other depending on the device width.
If you are on most tablets visiting the website in portrait and change to landscape you'll have to download the >768px UI after already downloading the <768px UI.
The mobile first approach in zb4 (with media queries) allow you to prevent stuff that belongs to big devices to be downloaded in to small devices. Basically you start with mobile styles and if the device meets the conditions you set on your mediaqueries (you can have much more breakpoints than the zf4 framework gives you by default) then the next rule jumps in.
I have worked in several 'responsive' projects even back in the pre-mediaqueries days were I use javascript to measure windowsize
Regarding javascript and like #powjames3 said zepto is much lighter / faster than jquery and if you could write your own javacript functions will be much better than using a over-bloated library.
Nowadays I do mobileFirst responsive webapps and websites use a mix of user agent sniffing ( sometimes to decide what image src or script / style src to deliver), despite the decision of the user agent tests i always serve mobile first mediaqueries, and conditionally loaded content.
"As Ethan Marcote (and John Allsopp before him), were right to point out, the inherent flexibility of the web is a feature, not a bug."
Here are some resources that might put you in the right track:
User agent parse and detection:http://mobiledetect.net/
Tutorial http://www.html5rocks.com/en/mobile/responsivedesign/ that covers:
Why we need to create mobile-first, responsive, adaptive experiences
How to structure HTML for an adaptive site in order to optimize performance and - prioritize flexibility
How to write CSS that defines shared styles first, builds up styles for larger screens with media queries, and uses relative units
How to write unobtrusive Javascript to conditionally load in content fragments, take advantage of touch events and geolocation
What we could do to further enhance our adaptive experience
Hope it helps
I've been looking into adopting MvvmCross in developing our next generation of software, mainly with the aim of developing tablet UIs for it. I understand that MvvmCross does not currently support WPF but I can see ourselves developing that and contributing it back.
However, I've also noticed that MvvmCross seems to be very light weight in that there is little support for composite UI as described in the Prism guide.
Unfortunately, we do need to allow for more complex composited UI scenarios.
Given what is stated in https://stackoverflow.com/questions/10224376/mvvmcross-experiences-hindsight-limitations about forking or rolling your own with MvvmCross as a reference, and given that we do need more complex UI scenarios than those that MvvmCross provides, what would the best course of action be, fork and reimplement the parts of prism we need, try to get MvvmCross to work together with Prism as is, or develop our own from the inspiration of MvvmCross and MonoCross?
Update: See Second answer below...
I might need to write a longer answer to this tomorrow...
As an initial answer:
someone has already done a port of MvvmCross to Silverlight and the developers have suggested this might become available to the wider community
the PCL version of MvvmCross should be quite straight-forward to port to WPF - although possibly not if older .Net Runtime versions are required
as the chief dev of MvvmCross to date, I'm personally interested in supporting WPF - especially right now for my project http://github.com/slodge/BallControl which needs a desktop to run in (Windows Store is crippled - pah!)
composite UIs are supported in MvvmCross - e.g. tabs, pivots, panoramas, splits, modal children, etc - but there's not much work been done yet on a full composite UI like often seen in Prism.
I have seen people combine MvvmCross with other IoC frameworks, but (no work that I know of) has been done to date on combining MvvmCross with MEF (which is often used with Prism?)
If I were tackling this problem area, then I'd come at this:
Make sure we try to get a working app out first and foremost - the app matters more than the framework.
For framework, I'd try porting the basic IoC setup across first and some simple navigation
For the custom navigation (for displaying UIs in regions) I'd look at the role of the Presenter in MvvmCross - this is what I use in Tab examples, in iPad split view examples, etc to provide complex UI features.
If this custom navigation isn't enough I'd look at how it might be changed/replaced/extended - my guess is that the genuine requirements for WPF/Prism will actually be quite similar to the genuine requirements for bigger iPad, Surface and Nexus tablet apps.
I'd try to keep everything modular and optional so that small phone apps don't have to pull in big navigation processes that bigger apps might need. The downside of this might be lots of projects and DLLs!
I'd also be open to this splitting into separate project(s) - much of the modern software world is ruled by small targetted apps rather than bigger, sprawling frameworks.
Because I'm part time on Mvx, and this is your full time job, I'd definitely recommend you don't let Mvx hold you back!
My initial reaction is 'yes, I'd be really interested in working on this' - the downside (as above) is that I'm only spare time on mvx....
Here's the second answer...
I took the WinRT version of MvvmCross as a base (but also used elements of Console, WP7, Touch and Droid too)
I produced a simple WPF version of MvvmCross - https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/Cirrious.MvvmCross.Wpf
The main feature of this version is that it doesn't contain much in the way of navigation
e.g. don't try calling Back!
e.g. the main presenter is left abstract for the application UI to implement - see https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.Wpf/Views/MvxWpfViewPresenter.cs
I then took the TwitterSearch demo app - https://github.com/slodge/MvvmCross/tree/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf
created some simple views (using cut and paste of Xaml from WP7 version)
created a simple Region based presenter - see how RegionAttribute is used in https://github.com/slodge/MvvmCross/blob/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf/MultiRegionPresenter.cs and in https://github.com/slodge/MvvmCross/blob/vnext/Sample%20-%20TwitterSearch/TwitterSearch.UI.Wpf/MainWindow.xaml.cs
that was kind of it... give or take a couple of hours of debugging
There's a video of this in action - with some explanation at: http://youtu.be/pYkLxqpu_5E
This is obviously only a first step in Wpf support, but I suspect it is already going to satisfy quite a few use cases... Please feel free to fork the source tree and to extend or replace this first attempt. Also, if it doesn't work for you, then feel free to abandon it and try something else instead.
I will try to work on this more - but can't really prioritise it above paid work... but I am open to being paid to work on mvvmcross too :)