i am using ng-animate with ng-repeat.
The elements that appear and disappear are happening smoothly, but the case where some elements disappear, and the remainging elements are moving to the left is taking place abruptly.
How do i smoothen the movement of the left over elements ?
Do ask for more explanation if the requirement is not clear.
Thanks in advance
I had this problem when binding a lot of data.
I found this plugin incredibly useful and lightweight: http://binarymuse.github.io/ngInfiniteScroll/
I would definitely recommend it. It hugely improved initial page load times too.
Related
Okay so i have used Figma before, although it was long ago, i didnt have this problem. I am in a team of developers. we arent very good in designing so we paid a designer to do the design for us. Everything was all good till i started coding the landing page. The dimensions i got from Figma for basically everything is way too big and so unrealistic. I mean it told me that the height of the Navbar is 135px, 135?????? thats way too big for a Navbar. I have to scale it down myself and use trial and error method till it looks somewhat like the design. Normally i wouldnt complain if i was programming for myself but its not a personal project and i am on a deadline so the fact that i have to manually use trial and error method to make the designs match instead is just adding so much time that i didnt account for. Is this a fault of the designer or figma itself? is there a way to scale down the dimensions to make it browser-size ?
The first thing to understand is that if your screen has a higher resolution, it may look smaller or larger.
Second, your designer did his designs on a different scale.
You will have to make a system of scales. If he gave you the height as 135px and you think 80px is actually the correct value, your scale is 0.6 and all values should be passed as height x 0.6. Same way for the width.
The easiest way is for the designer to resize his design to the correct size. This will have only one drawback and that's he will have to edit multiple elements in each page individually and it can take hours. However, it's his mistake.
The problem
Today's modern websites may use infinite scrolling technique to replace paged lists to make a more seamless experience to their users.
This is all nice and dandy as long as users don't scroll to far down which means that your document becomes very complex with huge amounts of DOM nodes. There are of course ways to mitigate this problem (i.e. replacing over-top overflowed scrolled elements with a single DIV of appropriate height for example), but they're either complex to implement and they still have their flaws.
The idea
I was thinking if anyone has already seen an implementation where items, that get scrolled out (top or bottom) somehow become smaller and fainter until they disappear and get replaced by its adjacent item.
I'm thinking of a mix of experience of:
scrolling
fading
scaling
Fading and scaling can be seen on Medium.com when you get to the bottom of any article and you click the next recommended one displayed below (click the title). When you do click and if you pay attention you can see the effect of original article disappearing while being replaced by an up-sliding new article.
Content scrolling could be done in this way and infinite scrolling would be much smoother and less resource consuming as elements would get replaced on the fly and in-place.
Number of simultaneously displayed items of course depends on items' size. In case of Medium-line articles it would likely be one article that would also scroll until you'd scroll it to the very bottom (or top). In case of posts like Facebook, it would be many more items simultaneously as they don't take as much vertical space.
Coverflow works in somewhat similar way as it displays middle content completely and rest is either hidden or scaled/transformed.
The question
Has anybody seen such an implementation on the web? If done properly it would actually make a much nicer infinite scrolling experience without hogging our browsers.
But to make my question more clear and non-debatable. Can you provide a working (albeit simplified) example of such experience?
Requirements:
when an item gets scrolled out it disappears (using fade/scale/both)
when items appear at the bottom (or top when scrolled up) they should display in the opposite to scrolled out items
pressing usual scrolling buttons Home, End, Page Up, Page Down and Space should work.
invisible items should be removed from DOM
scrolling should somehow be available using some sort of scrollbar as well
I think I might have found what you were looking for.
http://engineering.linkedin.com/linkedin-ipad-5-techniques-smooth-infinite-scrolling-html5
I am currently working on a user interface, in which it is possible, to add objects by clicking on the screen. I don't want any overlapping objects. While it is easy to detect, whether a collision between 2 objects occurred, i am still struggling with resolving these conflicts.
Currently, i am resolving the conflicts locally by moving the intruding object away from the collision. This, however, may lead to new collisions, which are resolved in the same manner. Unfortunately, there is no guarantee, that this process will ever stop.
Are there any standard problems this relates to or algorithms to use? Or any efficient solutions which are not prone to endless recursion?
Now that I thought of it more I think you just move all the objects that lie in the direction of the move that you are already doing. Doing it this way you basically solve the problem of possible endless recursion.
Since you should know the size of your objects to move and the direction of a smart movement this should solve the problem
"grid snap" is avoiding the problem but not a solution to the problem.
As Sarah pointed out you can solve this by moving your objects a random distance into one direction and then check again if there is a collision, then move the colliding object. However, this can lead to exponential growth of the problem.
Instead you can try to implement a light physics engine where your objects "bounce" against each other and using friction come to a halt after some time. Try to google for continuous collision avoidance.
The easiest way I can think of how you can resolve your problems is by implementing a "grid snap" behavior.
Basically, there are only predefined areas in your frame where the user can add UI elements---the grid cells. When a user drops a UI element on your frame, you should detect where in the grid does it fall mainly (you can choose your own behavior in case it falls equally across two or more grid cells). This way, you need not detect collision between two UI elements at all.
Edit
Well, I certainly did not anticipate the cases you outlined in your comment. If the sizes of your objects will vary by that much, I admit that "grid snap" may not be applicable to your situation---you might end up with a lot of empty space. I was thinking of something along the lines of Visual Basic when I composed my answer (VB, as far as I remember does implement some sort of grid snap behavior).
A minor point though: while you may have your user's best interests at heart by letting them have an exact control of the positioning of UI elements, think of how your users will interface with your program. Positioning things exactly on the screen using a mouse can be punishment and it may just backfire on you. The same, however, cannot be said if you are guaranteed that your users will always use a touchscreen device.
My project's creative designer and I have had some amicable disagreements as far as whether it is better to use slices of his comp or rely on the browser's rendering engine to create certain aspects of the user experience.
One specific example is with a horizontal "bar" that runs the entire width of the widget. He created a really snazzy gradient that involves several stops of different colors and opacities, and he feels that the small size of the image is preferable or at least comparable to the added lines of CSS code needed to generate the gradient natively.
We're already using CSS sprite technique to reduce the number of return trips from the server so that's not an issue for us. Right now it's simply the pro's and con's of using sliced up imagery versus rendering with CSS and HTML.
Is there a definitive rule as to how large an image needs to be to be the "worse" option of the two?
UPDATE: Since a few people have mentioned the complexity of the gradient as a factor I'm going to present it here:
-webkit-gradient(linear, left top, left bottom, color-stop(50%, rgb(0,0,0)), to(rgba(0,0,0,0.9)));
Very complex! ;-)
Measure it! Not the answer you like I think, but it really depends how complex the CSS will be and therefore how long it takes to be rendered.
In most cases it'll be the render time (CSS version) vs. request overhead and transmission time (image version). You will most probably see the big numbers here. Since you're already using image sprites you're reducing the request overhead to a minimum.
Browser compatibility should also be something you should be aware of. Here images will often win over CSS when it comes to gradients and something like that.
Some very complex CSS3-site to demonstrate what I mean: http://lea.verou.me/css3patterns/
This is a VERY nice case study, but incredible slow. It lags when loading. It lags even more when scrolling. And I am sure it is much slower than a solution using an image sprite for all of that.
Don't treat me wrong! I love CSS, but images are fine too. Sometimes even finer.
Summary
Measure it! When you do not have the time to measure, then estimate how complex the css would be. When it tends to get complex, then use images. When you've compatibility issues, then use images.
In general, if it can be done with CSS, definitely skip the image. If for no other reason it's easier to maintain.
HOWEVER, a complex gradient is likely where I'd give in and throw in an image. Having recently implemented some CSS gradients, it is a bit of a mess right now.
Ultimately, Fabian Barney has the correct answer. If it's an issue of performance, you need to measure things. In the grand scheme of things, this is likely low on the performance issues to dwell on.
i think CSS is more reusable. Imagine you have to repeat the same image over and over again in the same web document. Lots of HTTP requests there. But that's my opinion, please correct me if I'm wrong I think CSS is way more expressive and flexibly stylish.
However, there are things you have to watch out for. Stuff like browser specific prefixing kill pages with too much CSS.
Is it possible to virtualize both horizontally and vertically?
All examples show one or the other.
Imagine a large grid like structure:
n amount of rows
and as many columns as there are hours in one month
At any one point only 4 rows maybe on screen showing only 2 columns (2 hours). Virtualization one way doesn't make sense. This is an up down / left to right scrollable grid.
I ask because I can't for life of me find any examples online? Also I can't find anyone else who has had the same query. Maybe the design in general is wrong or I don't quite know what I'm searching for.
I did think the design maybe wrong i.e. is there a better alternative but I don't think so. This planner-like-grid is required! The only other consideration I had was to dyanmically build pivot pages but this seems messy and won't have the same feel.
Can anyone begin to advise were I might look?
Whether right or wrong, the direction I'm going in is the following. I wanted to post one answer for any one stumbling across the question.
Using a grid, I'm creating a 2 x 2 grid. Top right, bottom left and bottom right will all contain scroll viewers. The scroll viewer in the bottom right when scrolled will dyanmically change the scroll position of the bottom left scroll viewer and top right scroll viewer. Similar scroll top right will dyanmically scroll bottom right, and bottom left will scroll bottom right.
Obviously a lot of scroll viewer bindings but this is one solution which will work in order to give me the planner functionality and layout.
In terms of the virtualization I am dyanmically going to queue controls in order to keep the performance decent, reusing controls where required.