Search Results

Search found 2 results on 1 pages for 'matey'.

Page 1/1 | 1 

  • Producing dynamically generated range names in Excel using c#

    - by Matey
    What is the best way to produce several tables of unknown size on the same worksheet? Values will be pulled from an oracle database and are used as values on several tables. Is it possible to create dynamic named ranges or is some other method desirable? I have some experience with c# but do not have access to VSTO 2005. Any help or suggestions would be greatly appreciated. I am willing to explain the problem further if requested.

    Read the article

  • Navigation in Win8 Metro Style applications

    - by Dennis Vroegop
    In Windows 8, Touch is, as they say, a first class citizen. Now, to be honest: they also said that in Windows 7. However in Win8 this is actually true. Applications are meant to be used by touch. Yes, you can still use mouse, keyboard and pen and your apps should take that into account but touch is where you should focus on initially. Will all users have touch enabled devices? No, not in the first place. I don’t think touchscreens will be on every device sold next year. But in 5 years? Who knows? Don’t forget: if your app is successful it will be around for a long time and by that time touchscreens will be everywhere. Another reason to embrace touch is that it’s easier to develop a touch-oriented app and then to make sure that keyboard, nouse and pen work as doing it the other way around. Porting a mouse-based application to a touch based application almost never works. The reverse gives you much more chances for success. That being said, there are some things that you need to think about. Most people have more than one finger, while most users only use one mouse at the time. Still, most touch-developers translate their mouse-knowledge to the touch and think they did a good job. Martin Tirion from Microsoft said that since Touch is a new language people face the same challenges they do when learning a new real spoken language. The first thing people try when learning a new language is simply replace the words in their native language to the newly learned words. At first they don’t care about grammar. To a native speaker of that other language this sounds all wrong but they still will be able to understand what the intention was. If you don’t believe me: try Google translate to translate something for you from your language to another and then back and see what happens. The same thing happens with Touch. Most developers translate a mouse-click into a tap-event and think they’re done. Well matey, you’re not done. Not by far. There are things you can do with a mouse that you cannot do with touch. Think hover. A mouse has the ability to ‘slide’ over UI elements. Touch doesn’t (I know: with Pen you can do this but I’m talking about actual fingers here). A touch is either there or it isn’t. And right-click? Forget about it. A click is a click.  Yes, you have more than one finger but the machine doesn’t know which finger you use… The other way around is also true. Like I said: most users only have one mouse but they are likely to have more than one finger. So how do we take that into account? Thinking about this is really worth the time: you might come up with some surprisingly good ideas! Still: don’t forget that not every user has touch-enabled hardware so make sure your app is useable for both groups. Keep this in mind: we’re going to need it later on! Now. Apps should be easy to use. You don’t want your user to read through pages and pages of documentation before they can use the app. Imagine that spotter next to an airfield suddenly seeing a prototype of a Concorde 2 landing on the nearby runway. He probably wants to enter that information in our app NOW and not after he’s taken a 3 day course. Even if he still has to download the app, install it for the first time and then run it he should be on his way immediately. At least, fast enough to note down the details of that unique, rare and possibly exciting sighting he just did. So.. How do we do this? Well, I am not talking about games here. Games are in a league of their own. They fall outside the scope of the apps I am describing. But all the others can roughly be characterized as being one of two flavors: the navigation is either flat or hierarchical. That’s it. And if it’s hierarchical it’s no more than three levels deep. Not more. Your users will get lost otherwise and we don’t want that. Flat is simple. Just imagine we have one screen that is as high as our physical screen is and as wide as you need it to be. Don’t worry if it doesn’t fit on the screen: people can scroll to the right and left. Don’t combine up/down and left/right scrolling: it’s confusing. Next to that, since most users will hold their device in landscape mode it’s very natural to scroll horizontal. So let’s use that when we have a flat model. The same applies to the hierarchical model. Try to have at most three levels. If you need more space, find a way to group the items in such a way that you can fit it in three, very wide lanes. At the highest level we have the so called hub level. This is the entry point of the app and as such it should give the user an immediate feeling of what the app is all about. If your app has categories if items then you might show these categories here. And while you’re at it: also show 2 or 3 of the items itself here to give the user a taste of what lies beneath. If the user selects a category you go to the section part. Here you show several sections (again, go as wide as you need) with again some detail examples. After that: the details layer shows each item. By giving some samples of the underlaying layer you achieve several things: you make the layer attractive by showing several different things, you show some highlights so the user sees actual content and you provide a shortcut to the layers underneath. The image below is borrowed from the http://design.windows.com website which has tons and tons of examples: For our app we’ll use this layout. So what will we show? Well, let’s see what sorts of features our app has to offer. I’ll repeat them here: Note planes Add pictures of that plane Notify friends of new spots Share new spots on social media Write down arrival times Write down departure times Write down the runway they take I am sure you can think of some more items but for now we'll use these. In the hub we’ll show something that represents “Spots”, “Friends”, “Social”. Apparently we have an inner list of spotter-friends that are in the app, while we also have to whole world in social. In the layer below we show something else, depending on what the user choose. When they choose “Spots” we’ll display the last spots, last spots by our friends (so we can actually jump from this category to the one next to it) and so on. When they choose a “spot” (or press the + icon in the App bar, which I’ll talk about next time) they go to the lowest and final level that shows details about that spot, including a picture, date and time and the notes belonging to that entry. You’d be amazed at how easy it is to organize your app this way. If you don’t have enough room in these three layers you probably could easily get away with grouping items. Take a look at our hub: we have three completely different things in one place. If you still can’t fit it all in in a logical and consistent way, chances are you are trying to do too much in this app. Go back to your mission statement, determine if it is specific enough and if your feature list helps that statement or makes it unclear. Go ahead. Give it a go! Next time we’ll talk about the look and feel, the charms and the app-bar….

    Read the article

1