Working on my personal website, I am trying to implement the Intersection Observer API for navigation items active state management, such as the example we see here : http://intersection-scrollspy.surge.sh/
The problem is that, contrary to the demo where each section is equally tall / or is at least 100vh tall, I have sections that vary in size. In fact, the two last sections on my page are not tall enough when you zoom out the page, which screws the Observer mechanism... (Basically my last two sections are never "observed" and so the active states are never triggered for last two items of the navigation menu). This is problematic for higher resolution screens (or when a user just decides to zoom out the content) ...
I've tried to find a solution to that problem, but I am literraly stuck ... However I know that a solution must exist because this example website (https://prorez.caliberthemes.com/resume/) found a solution which works no matter what the zoom on the page is (it does not use the intersection observer though, if I am not mistaken) ...
Do you have any idea how I could solve that issue?
Thanks a lot
Related
I've read many posts about this, but never found something satisfying and I wonder if perhaps new techniques have been developed since those posts.
Basically, I have a fixed navigation header on my site, and a search bar that will get nested and fixed just under it as users start scrolling down.
Most of my anchor/section links are located on different pages than where the user is getting re-directed to when clicking them (so, no "smooth scroll" is happening).
I cannot add padding or a class manually to each of these points because most of them are generated automatically...
Is there perhaps some jquery I could apply that would automatically show these anchor/sections point lower in the screen?
Help :)
I'm experimenting with creating a metro style app with Visual Studio 2012, I am not the most experienced designer but one thing with my applications is confusing me.
I have been working with 'basic pages' instead of blank ones for the different pages in my application for design consistency, however it seems that these 'basic pages' have a strange behaviour. Every item I place on the page (buttons, text boxes, etc) will all slide in one by one when the page opens. For example if I run the application and navigate to a page with 10 buttons, it will do a brief animation where each button will slide in from the right side to the left side. When dealing with a large number of items on one page this can take a lot of time as each item slides in seperatley.
Looking at the properties for each item I have been able to change the direction it slides in while loading the page by changing the flow direction. Also with a bit of research I am thinking it could potentially be due to either the metro style 'enterPage' or 'enterContent' animations, though I can not be certain.
I have tried to experiment and figure this out, and search to find out what causes this so I can modify it (Ideally I would like to just group items together to slide in with each other) however it's kind of a difficult thing to search with vague words, so I'm asking here.
What is causing this and how might I go about modifying it?
EnterPage shouldn't be sequencing the animations. They do offset some of the animations of a number of elements, but it shouldn't be each one sequentially.
Are you using WinJS navigation?
Well after a bit of experimentation I figured out that putting all my page content inside a grid made them all come in at once like I wanted. I probably should have tried that earlier but everything was already inside an outer grid for the page, so I thought that woulda handled it.
I don't quite understand it fully, but that works for now.
I am working with flex for the last two years on some desktop apps. Until now I never had any performance related issues but today as we completed a mobile application for the iPad, I'm facing a challenge, the application is incredibly slow on the iPad.
http://i.stack.imgur.com/qkbWn.png
Slow, means that when I press a button in the menu to change the splitview I must wait something like 5s. Then scrolling is really slow two, with less than one fps and my TextInput starts to bug (the text is not in his box anymore).
I started to read a lot of blog post and presentation about optimisation for the mobile platform and then I rewrite some of the components I use. I removed the SkinnableContainer for instance and replaced it by a VGroup including some actionScript based drawing.
Now what you see is a VGroup (the dark grey one) containing some others VGroup (the group with title here) and then each widget is an HGroup with a label and a Widget. I only use Label and TextInput for the text.
Creation time is slow even (several seconds to create the view) for another page where there is only 4 text widget on it, or another one with only a list with a custom item renderer where each row is a set of 4 labels.
The whole things is cabled with RobotLegs, with nothing fancy, one models is injected in the view and at the beginning I set a member variable on the view with this object to bind my variables.
Frankly my thinking right now is : it smells fishy because if I've done everything right it is impossible to have such low performance and thinks that flex is competitive on the mobile platform. So right now I'm trying to disable the application piece by piece to try to locate what could slow it like that. I've got a couple suspects to check, for instance I've got some binding warning to check, and then see if robotlegs has got its share of the problem.
So my main question here is what do you think, and could you have some ideas about "is there a problem" and "how do we solve it".
Thanks
Run profiler for startup and separatelly for each operation that takes longed that it needs. Then prioritize the problems and try to solve them with basic optimization techniques.
Some problems you will not be able to solve fast - e.g. time for creating big components. The only option there is to rewrite those components with AS3 without MXML, styles and anything. I'm sure that flash.text.TextField is created many times faster than mx.controls.Label. The same for other components.
When component is created, it can be reused at a very low price. In your app there must be a lot of places where you recreate while you can reuse old components. It will save you memory and time.
Layouts tend to redraw even when it's not needed. If you have a lot of nested layouts, find the most critical places and replace a series of layouts with one custom layout or even component.
This all is very developer time consuming. At the end you will not get a smooth app anyway, but I believe that it can become usable.
As Cody Gray mentioned when answering my other question here, Raymond Chen talks about how icon overlays are a poor choice here (note that the article is a year old).
The substantive argument against overlays is that only one can be shown at a time... so if two apply, which one wins? The specious argument is that there can only be 15 - which in my opinion is a design choice by Microsoft, not an argument against their efficacy.
With the changing topology of file:
location
management
ownership
synchronization
replication
?????
I believe Files and folders need the equivalent of presence indicators to instantly identify their status.
What is an alternative to icon overlays that presents the same instant visual queue on the status of a file/folder? Maybe there needs to be a new model for icons?
Edit:
2010-12-14
The more I've thought about this, the more I feel that the idea that there can only be ONE overlay and that there's no way to make overlays work together is ridiculous.
Unless there's a technical reason you cannot have more than one overlay?
Consider (off the top of my head):
You could segment the icon into 4 quadrants (upper left, upper right, etc) - this would allow for 4 overlays per icon. No inter-overlay adaptation required.
You could stack overlays, and ONLY use priority to determine position (z-order anybody?). Allow the user access to User-space priorities, so the USER (you know, the person who the software is supposed to serve?) can choose which overlays matter. Rather than reserving a spot for an overlay, system overlays have the highest priority.
If there is one condition needing an overlay, simply show the one overlay.
If there is more than one condition needing an overlay, layer them all as suggested in the question. Then, the window manager would need to provide an extra UI element indicating that "there's more to know here". Perhaps it only shows up on a mouse hover? Anyway, clicking on that element could show details about the overlay conditions for those who REALLY want to know, but it would be hidden away for the 99.99% of the time when no one cares.
One way would be to add a new Status column in details view, displaying the "presence indicator" in localized plain text.
It would be accessible, wouldn't mess with the file's icon, and would be understandable by all users regardless of their culture or their possible ailments.
I've found many answers, here or inside MS' UI guidelines, regarding button positioning, but none about how to position (in which order) buttons when you have three actions to do, New, Edit and Delete.
I have a simple UI, in the upper part I placed a grid listing some data. Beneath, these three buttons. Following what I see around, I have to place them in this order:
New - Edit - Delete
But it seems to me that the delete button is more prevalent and easier to reach and click than the others (it falls on the lower-right corner of my window).
Any suggestion?
I think the order you cite (New - Edit - Delete) is most common because you would logically tab order from left to right when using the keyboard. New would arguably be the most used button (possibly edit depending on the application, but rarely delete) and therefore you wold want the fewest tabs to get to the New button.
Column layouts are always good for these kind of buttons, as one has to move the cursor into the button area, which is horizontally slight and therefore less likely to be accidentally clicked.
Also it provides a perceived division from the main GUI widgets, instead of spanning their length, which tends to create less of a perceived division in the user's mind.
But if you do not wish to change the overall layout, I would say that your current layout is good. Maybe add a delete confirmation box if one is not already present.